Is Golang a good choice for a CRUD based ReST API?

<p>I&#39;m working on a project that is as the title states. I want to make a ReST API with PostgreSQL as the database. It also uses JWT with Auth0. It seems people recommend net/http + database/sql for web stuff. Have people here had good experiences with projects like these in Go?</p> <p>Also, what do you folder structure do you recommend?</p> <hr/>**评论：**<br/><br/>condanky: <pre><p>Of course Go is good for CRUD operations, however there are frameworks out there, ie Rails, that will get you up and going much faster than with Go. It just depends on what the scope of the project will be, performance, what languages you already know etc. As for project layout following this <a href="https://github.com/golang-standards/project-layout" rel="nofollow">https://github.com/golang-standards/project-layout</a> is pretty solid. There is also this you can check out <a href="https://talks.golang.org/2014/organizeio.slide#1" rel="nofollow">https://talks.golang.org/2014/organizeio.slide#1</a></p></pre>theta_d: <pre><p>I&#39;ve built several REST style services using Go. Working with Postgres in Go is pretty straight-forward. We also used JWTs and Auth0.</p> <p>As for folder structure, keep it simple. I have a file for routes, files for data access code, and wire them up in main. Really only create more folders if the source root starts to get unwieldy.</p></pre>kapoof_euw: <pre><p>Just to add on this if it would not be clear to OP, keep your files such as &#34;routes&#34; and data access code away from your &#34;main&#34; package. Code in the &#34;main&#34; package is not available for use in other components in Go, meaning that code is private for your 1 component.</p> <p>I&#39;ve seen new Go coders do this before, and you&#39;re stuck with a bunch of refactoring when you figure this one out ;)</p></pre>mackstann: <pre><p>I would recommend using higher level tools than just the Go stldlib.</p> <p>My project started off as &#34;just net/http&#34; and &#34;just database/sql&#34; and now we have lots of dumb boilerplate code (riddled with one-off inconsistencies) to list all the columns for writing queries, scan them back into Go, etc. The models used inside the API are too highly coupled to the objects we send over http (thanks to &#34;just use json tags&#34;). It&#39;s crude and has caused a ton of technical debt and inappropriate coupling.</p> <p>Unfortunately, I don&#39;t really know what I recommend. Big frameworks can be like handcuffs, and dynamic languages leave more surprises until runtime. I guess there&#39;s no silver bullet, eh?</p></pre>BubuX: <pre><p>That&#39;s amazing feedback. Thank you!</p> <p>What would you say about C# .NET Core in this case?</p></pre>mackstann: <pre><p>Unfortunately I have no idea -- I&#39;ve always been on the open source/Linux side of things.</p></pre>AmateurLlama: <pre><p>Do you think Flask would be a good choice for something like this?</p></pre>gibsonsyd: <pre><p>Been using C# with Entity Framework as a ORM for SQL. Tooling is always important in considering an MVP for us BUT the flip side of the coin you have to consider your teams proficiency in the language you choose. In general I can recommend C# .Net Core as a great way to get stuff out quickly. C# remains my favourite goto lang and with .Net Core it cross compiles to Unix platforms if you are looking at Linux docker deployment in a cloud env.</p></pre>