<p>Whenever I want to make a web applications, I always get stuck writing the API endpoints. It seems that writing APIs involves writing a wholelot of boilerplate, which I hate to write. A lot of functionality seems reusable too. What solutions do people here use?</p>
<p>Generally, my web applications need the following features: authentication and authorization (login, register, account recovery, ...), rate limiting, pagination, other WHERE clauses (since data is fed from a DB).</p>
<p>Would you use a RESTful API using JSON responses? Would you use a (g)RPC approach (or why not)? WebSocket is only useful if there is not a request-response type of communication, but streaming or message passing. The authentication part could be done using <a href="https://github.com/go-authboss/authboss" rel="nofollow">https://github.com/go-authboss/authboss</a>. But what about all these endpoints for all your methods? So much boilerplate, also clientside. I quite like how in gRPC you can define a protocol and reuse those client side (I don't get why browser support was considered so late though).</p>
<p>Concluding, it would be nice to have a standard solution for a web application that could be reused. Does anybody have examples?</p>
<p>PS: I quite like the idea of having a static website that uses AJAX to load in data. This way the website can be fully cached and nicely separates the server and the client. You could also use the classical approach of generating webpages using templates. That would eliminate the need for an API. What do you prefer?</p>
<hr/>**评论：**<br/><br/>tdewolff: <pre><p>Apparently it's called JAMstack when you have a static site with AJAX to a serverside API: <a href="https://jamstack.org/" rel="nofollow">https://jamstack.org/</a></p>
<p>But would you use that when you have fairly tight coupling, such as a simple blog CMS?</p></pre>jackmcmorrow: <pre><p>I don't really understand why generating a static site if you need anything more than a landing page. </p></pre>Redundancy_: <pre><p>There's nothing to attack or defend, it caches exceedingly well, you don't need to pay for instances.</p></pre>jackmcmorrow: <pre><p>You also can't do searches, can't give your client a backend (that I know of) can't have user interaction outside third party services and have to deploy every time you want to update the site.</p>
<p>Again, can't see that much advantages over a simple CMS. Unless you're a Dev, and it's your personal site, then fuck user experience</p></pre>Redundancy_: <pre><p>We saved thousands of dollars (more if you consider the sysadmin, update and other costs).</p>
<p>There are a large number of sites that are largely static, except when a admin/dev posts new content to them. You don't need databases, nginx or instances for all of that - you can use S3 and Cloudfront, or your favourite alternative.</p>
<p>Then you consolidate the things you actually need to be dynamic based on user input down to an API.</p></pre>jackmcmorrow: <pre><p>If you say so. I'm still skeptical, the use case is really important, are you developing a site for someone or you have a team behind the site?</p></pre>Redundancy_: <pre><p>These were frequently web sites where customer relations people would periodically post new content. We had a CMS on the backend, but pretty much just ended up baking out a static version of the site from staging and uploading it. Previously there were maybe 6 machines which were spending a large amount of their time doing nothing much interesting at all - checking databases for content that wasn't changed.</p>
<p>The traffic to our origin servers was massively offloaded, and we didn't need to worry about DDOS attacks or most other things that previously would also have affected our websites. QA was simplified, because if you checked what you baked, you'd get exactly that in prod.</p>
<p>Something like gohugo.io could get you a very long way, very cheaply.</p></pre>tdewolff: <pre><p>Of course you can, do an AJAX request with the search terms, send back the results in JSON and render them using HTML templates using JS. This way the search functionality is completely modularized and could be reused in multiple spots.</p>
<p>I wouldn't mind a backend that has dynamic pages, but it's the frontend that could be completely decoupled using an API.</p></pre>shovelpost: <pre><blockquote>
<p>It seems that writing APIs involves writing a wholelot of boilerplate, which I hate to write.</p>
</blockquote>
<p>You might have chosen the wrong tool for the job then. Have you considered Ruby?</p></pre>kaeshiwaza: <pre><p>The "classical approach of generating webpages using templates" is also fine with Go...</p></pre>shovelpost: <pre><p>I don't disagree but that requires even more boilerplate which apparently the OP hates.</p></pre>cameronjerrellnewton: <pre><p>I like to think of go as a pragmatists language. It was made for specific solutions (hence the lack of generics), while still allowing moderate flexibility when it's called for. </p>
<p>As it turns out, a lot of these generic solutions never live up to their promises. There are always subtle differences between implementation to implementation that makes or breaks an application. If there werent, someone would have automated it by now and we'd all be out of work.</p>
<p>I have embraced the fact that today's business problems might not be tomorrow's, and I'm probably going to throw away an implementation or two (Fred Brooks anyone?) until the problem is complete solved, at which point it only needs maintanence.</p></pre>
