<p>disclaimer: I know this is a broad question with no correct answer, but I'm looking for suggestions as well as real world experiences.</p>
<p>I want to build a REST API in Go and I have some requirements to do so.</p>
<ol>
<li>Easy API versioning.</li>
<li>Swagger/OpenAPI spec generation from the code.</li>
<li>Some ORM-ish lib (not everyone on the team is that SQL savvy)</li>
</ol>
<p>Any suggestions for libs/frameworks to achieve this?</p>
<p>Thanks in advance :)</p>
<hr/>**评论：**<br/><br/>tacticoool: <pre><p>I'm very fond of grpc and then sticking <a href="https://github.com/grpc-ecosystem/grpc-gateway" rel="nofollow">https://github.com/grpc-ecosystem/grpc-gateway</a> in front of it.</p>
<p>The proto file used with grpc defines typed messages and your service endpoints, you then annotate your endpoints with the REST info you want. And it can generate openai yml.</p>
<p>As for ORM I'm not sure what the current favourite is, I am more in favour of just writing some SQL using the brilliant sqlx. Try perusing <a href="https://github.com/avelino/awesome-go/blob/master/README.md" rel="nofollow">https://github.com/avelino/awesome-go/blob/master/README.md</a> to see what suits you</p></pre>snowzach: <pre><p>I do exactly this. However, grpc can be a little bit of a pain. It's definitely not as easy as some of the other frameworks like gin or echo. With grpc, generally you need to know what your data will look like and dealing with arbitrary json is a pain. If you're doing microservices though it's probably the way to go.</p></pre>mgdepoo: <pre><p>Thanks, I'm having a look to this too, although I've never used grpc before :)</p></pre>zanven42: <pre><p>It's really a pain at first, but once you get the hang of it, it is amazing. Also consider grpc-web. The QOL improvements and how fast iterations can occur / major API changes. It's worth having a good test to see if it might suit your team better.</p></pre>Iggymacd: <pre><p>Give Goa a try. Auto generates much of the requirements you listed.</p></pre>mgdepoo: <pre><p>Thanks :)</p></pre>Glinux: <pre><p>This.</p></pre>kemitche: <pre><p>I've been using <a href="https://github.com/go-swagger/go-swagger/" rel="nofollow">go-swagger</a> for (2). It flips your intended model on its head, but also imo makes it easier to ensure that you build your API "documentation first" because it asks you to write your API spec, then generates (or updates) all your handlers and validators from that.</p>
<p>My workflow is:</p>
<ol>
<li>Update my OpenAPI spec to add/update a route.</li>
<li>Use go-swagger to regenerate all the validation, routing, models, etc.</li>
<li>Write/update business logic in the handler for the endpoint.</li>
</ol></pre>mgdepoo: <pre><p>Yes, this seems to be the default way (in node too), but I find it kind of disturbing to have to maintain the API spec, which for a couple endpoints can easily top 350+ loc, and for full fledged APIs can grow out of hand... I feel like the right way should be to auto-generate the spec from the code, and not vice versa.</p>
<p>I thought there would be some implementations of this, but I guess I was wrong. Thank you!</p></pre>kemitche: <pre><p>When I care about documenting an API, I care about it being accurate. For me, the best way for me to ensure an OpenAPI spec is exactly what I mean is for me to write it myself. In the past, I've used spec generators, and they always seem to miss some aspect of my logic - enough that I am always worried that the generated spec is wrong in some way.</p>
<p>When I write the spec first, I know it's what I want it to be, and if it's not what I want, I discover it when writing the code or sanity checking my endpoints.</p>
<p>That's just why I prefer spec first :)</p></pre>mgdepoo: <pre><p>Good point :)</p></pre>zevdg: <pre><p><a href="https://swaggerhub.com/blog/api-design/design-first-or-code-first-api-development/" rel="nofollow">Code-first vs design-first</a> is the general name for these two development workflows. It's mostly a matter of preference, but IMO the tools for design-first workflows tend to be much saner in the long run. It's much easier to generate idiomatic code from an API spec written in a very limited DSL than it is to generate a sane API spec from arbitrary code in a Turing complete general-purpose language. These kinds of tools often require you to learn a whole meta language of decorators (or struct tags or cli parameters or something) so that they can figure out which parts of your code are meant to be exposed.</p>
<p>My other beef with code first approaches is that it makes it very easy to accidentally change a public API and break compatibility with existing callers. With design-first workflows, it's always obvious when you are changing the public API.</p></pre>Ribice: <pre><p>There is a way to generate spec from code. I too had issues making it, therefore wrote a blog post with a tutorial. Will be publishing it before Monday.</p></pre>govision: <pre><p>This obviously won't run in go playground and nor is it production anything but it helps me template out a quick design. It's not pretty nor safe but it's me trying to muddle through something to just get it to work without a framework. There's a ton wrong with it but I think it'll help you if you never touched it before. At least in some ways...
I think when you get the ball rolling, you'll realize really quickly gorm and other frameworks just cause a giant headache. Cause not only does it really limit you but looking for documentation is a nightmare with them. Sure you can compare to Enterprise software with them because making tables inside tables inside tables is way easier but when it comes time for customizing, refactoring, benchmarking, errors, ect.. you'll run right back to vanilla. Believe me :)</p>
<p><a href="https://play.golang.org/p/-GQ-YWw5fu-" rel="nofollow">https://play.golang.org/p/-GQ-YWw5fu-</a></p>
<p>I go off these resources I compiled learning.</p>
<p><a href="https://docs.google.com/document/d/1Zb9GCWPKeEJ4Dyn2TkT-O3wJ8AFc-IMxZzTugNCjr-8/edit?usp=drivesdk" rel="nofollow">https://docs.google.com/document/d/1Zb9GCWPKeEJ4Dyn2TkT-O3wJ8AFc-IMxZzTugNCjr-8/edit?usp=drivesdk</a></p></pre>
