What's the most idiomatic API example for an enterprise golang server?

<p>&#34;Most idiomatic&#34; is subjective--and that&#39;s fine. What do you think is the most idiomatic golang server example on the internet? I&#39;m wanting to follow idiomatic patterns for the cli (spf13/cobra ?), for logging (logrus ?), for routing (net/http ?), middleware (std lib ?), for dockerizing (from scratch ?) etc. when developing my server code. </p> <hr/>**评论：**<br/><br/>shovelpost: <pre><p><a href="https://github.com/upspin/upspin">https://github.com/upspin/upspin</a></p></pre>blackjackjester: <pre><p>Preface: I&#39;m not a Go pro.</p> <p>I believe idiomatic go is &#34;only bring in a library if absolutely necessary&#34;, and generally avoid frameworks unless you are already familiar with the underlying implementation details, where possible.</p> <p>So for a web server, use net/http and template before using one of the many other frameworks or routing middleware. I don&#39;t think most Go projects require a comprehensive framework to accomplish most tasks.</p> <p>Unlike Ruby and RoR that run with DRY principles to a fault (imo), Go is less interested in &#34;perfect&#34; and more interested in simplicity in design.</p> <p>You may also get a better answer if you specify what sort of server? P2P, web server, distributed system, number crunching, DAL, etc. </p></pre>hudddb3: <pre><p>Yeah, I don&#39;t like to use 3rd party libraries if I can help it. This was my attempt at a canonical HTTP service, gained from experience with a few Go projects:</p> <p><a href="https://github.com/otoolep/go-httpd" rel="nofollow">https://github.com/otoolep/go-httpd</a></p></pre>rms1000watt: <pre><p>Thanks for the info!</p> <p>Just a basic REST-like API server. It might hit the data layer, it might hit a message queue, maybe crunch some numbers. I guess I&#39;m looking more for examples in enterprise environments. I mean, it&#39;s easy to hack something together, but creating a flexible server that stands the test of time takes a little more preparation. I figure being idiomatic would help meet that end. </p></pre>thelamacmdr: <pre><p>In this case you&#39;ll benefit from something like NGINX at the front as kind of a reverse proxy. This will handle a lot of the nitty gritty that you COULD do with Go if you wanted to but it would be a lot of work reinventing the wheel. </p> <p>Some reading material:</p> <p><a href="https://www.reddit.com/r/golang/comments/5i2vfh/newbie_question_how_does_a_golang_server_compare/" rel="nofollow">https://www.reddit.com/r/golang/comments/5i2vfh/newbie_question_how_does_a_golang_server_compare/</a> <a href="https://stackoverflow.com/questions/17776584/webserver-for-go-golang-webservices-using-nginx-or-not" rel="nofollow">https://stackoverflow.com/questions/17776584/webserver-for-go-golang-webservices-using-nginx-or-not</a> <a href="https://stackoverflow.com/questions/16770673/using-node-js-only-vs-using-node-js-with-apache-nginx" rel="nofollow">https://stackoverflow.com/questions/16770673/using-node-js-only-vs-using-node-js-with-apache-nginx</a></p></pre>gentleman_tech: <pre><p>I&#39;d look at Caddy instead of NGINX - it&#39;s written in Go and is more compatible if you want to get into doing funky stuff.</p> <p>I&#39;d completely second the &#34;no third party libraries unless you absolutely need them&#34; advice. The standard library really does have everything you need for this, and having dependencies will reduce your &#34;stand the test of time&#34; quality.</p> <p>Keep it simple, straightforward, easy to understand, and don&#39;t be afraid of a bit of boilerplate or repetition.</p> <p>Good luck :)</p></pre>adamtanner: <pre><p>You can get really far with just net/http, text/template, and encoding/json for web apps/APIs.</p> <p>If there&#39;s functionality you need you should generally prefer the stdlib to pulling in a third party dependency. I would start with the flag and log packages for cli and logging.</p> <p>Check out other libraries when you start building a feature where the stdlib is insufficient and either augmenting the stdlib or rewriting the functionality is tricky, error-prone, or requires a non-trivial amount of code.</p> <p>The only package I might recommend starting with would be httprouter instead of net/http.ServeMux just because you mentioned building REST APIs and I&#39;ve found the standard mux becomes somewhat painful to use if you&#39;re doing /:resource/:id/:nested/:nid style routing, switching on HTTP method, other RESTy things, etc.</p></pre>carsncode: <pre><p>This is why I&#39;ve abandoned the standard mux in favor of... nothing. I hard-code routing. A mux is a runtime configuration of completely static behavior, bringing all the performance penalties and very little benefit. On the other hand, I can chain a series of standard HTTP handlers, stripping path prefixes as I go, and deliver a highly efficient router with little effort, no dependencies, and support for whatever URL path hijinks I decide to implement, including stuff like a dynamic path parameter that is itself a path, something dynamic muxes are hard-pressed to offer.</p> <p>Is it harder to change the API this way - rearranging the routes requires a little refactoring. This, however, I don&#39;t mind at all; it should be at least as difficult to change my API as it is for my clients to change to accommodate it. Routes, once set, should rarely (if ever) change.</p></pre>