<p>I am trying to migrate Restful API built on RoR to GoLang. Which is the best framework which support all Postgres data types (specially inet, array and json). Also the other requirements are:
1. OAuth2
2. JSON
3. Google API access
4. File upload</p>
<p>Thanks</p>
<hr/>**评论：**<br/><br/>YuryOdin: <pre><p>as gophers say "It's not true golang way to work with big solid framework"
You can use something like base net/http lib or use smth like GIN and built it with other library's </p></pre>dhdersch: <pre><p>As others have said, Gophers tend to shy away from frameworks for things like this. That being said, there are a lot of libraries out there that are very helpful. For routing, I recommend <a href="http://www.gorillatoolkit.org/pkg/mux">GoRilla Mux</a>.</p></pre>pkieltyka: <pre><p>As many mentioned, in Go, theres no need to settle on a single framework that makes all your decisions - instead you can pick and choose your router, middlewares, responder, data access layer and templating system. Have a look <a href="https://github.com/avelino/awesome-go">https://github.com/avelino/awesome-go</a> and connect the pieces that fit your needs and tastes. The learning curve will be how to organize your app code so its maintainable.. search open source HTTP services written in Go to get some flavours/ideas. For APIs with many resources/routes, I'd suggest to look at chi, but I'm biased since I wrote it and used it at Pressly to build a >100 route rest API thats quite maintainable in a team of four. See <a href="https://github.com/pressly/chi/blob/master/_examples/rest/main.go">https://github.com/pressly/chi/blob/master/_examples/rest/main.go</a>. The idea is the API is built through function composition of handlers that pass data along via a request context (net/context). It helps. </p>
<p>The other part you'll need is a data access layer - I suggest <a href="https://github.com/gocraft/dbr">https://github.com/gocraft/dbr</a> , <a href="https://github.com/mgutz/dat">https://github.com/mgutz/dat</a> or <a href="https://github.com/upper/db/tree/v2">https://github.com/upper/db/tree/v2</a></p></pre>_kobra: <pre><p>Thanks for a detail response. </p></pre>Manbeardo: <pre><p>As mentioned by the other posts, frameworks aren't a great fit for Go. For http libraries, I've been quite pleased with <a href="https://github.com/emicklei/go-restful">go-restful</a> on my servers. It might sacrifice some performance, but it adds a ton of useful extensions over net/http.</p></pre>Ploobers: <pre><p>Check out <a href="http://goa.design">http://goa.design</a> | <a href="https://github.com/goadesign/goa">https://github.com/goadesign/goa</a></p>
<p>Unlike other frameworks, you start by designing your API interface. It then uses that to generate idiomatic Go code that you can build off of. Then for free, you get a Swagger definition, cli client, js client and other goodies.</p>
<p>If you are also interested in using an ORM, <a href="https://github.com/goadesign/gorma">https://github.com/goadesign/gorma</a> is a plugin that integrates with gorm. You can go soup to nuts with a JWT enabled REST API in about 10 minutes.</p></pre>iio7: <pre><p>I know this is most like gonna be down voted, but I see this framework tendency as a sickness of bad habits.</p>
<p>In PHP - as an example - nobody knows how to program themselves anymore, everyone is using frameworks for every little thing.</p>
<p>Some people "carry the sickness" with them and as soon as they begin using Go, they try to develop some kind of "framework" that they think the rest of the world cannot be without. Or they start looking for frameworks to use themselves.</p>
<p>But in Go this sickness has been cured and there is no need for frameworks at all. You actually need to program yourself, but since the standard library has everything you need to develop very clean and very simple and easy to understand code, it's quite easy and joyful.</p>
<p>I am sorry, but I hate frameworks. So naturally I really love the Go way!</p></pre>_kobra: <pre><p>I hope you don't get down voted. Everyone is entitled to there opinion and I don't find anything offensive in your comment :-)</p></pre>anonxgh: <pre><blockquote>
<p>Do not use frameworks, they are not conventional. Use bloated full of magic package that relies on <code>reflect</code> instead. We call it "toolkit".</p>
<p>Do not use frameworks, use <code>gorilla</code>. It will turn your <a href="https://github.com/mattermost/platform/blob/a9860a0ce8f1ce08dab9aaff0ec0c996de4f0e4c/web/web.go#L9">thousand lines of code in a single file</a> into a masterpiece automagically.</p>
<p>Frameworks are bad, toolkits are good.</p>
</blockquote>
<p>Are Go adepts that religious? How about defining exact things you do not like about some frameworks instead of turning "framework" into a four-letter word?</p></pre>nexusbees: <pre><blockquote>
<blockquote>
<p>Use bloated full of magic package that relies on reflect instead. </p>
</blockquote>
</blockquote>
<p>No one here was recommending a package using <code>reflect</code> as far as I'm aware. The only framework that uses <code>reflect</code> a lot is martini and even the author of that package doesn't recommend it any more.</p>
<p>I don't know what your problem with <code>gorilla/mux</code> is, but you've merely linked to a project that has many routes in its API. Maybe they could have split the code that handles the routes across multiple files, but <code>gorilla/mux</code> has nothing to do with that.</p>
<p>Regardless I'll take a stab at answering your question - go users generally prefer sticking to the standard library and adding other libraries (like <code>mux</code>) only when necessary. This makes the code base simpler to read, easier for newbies to hack on and arguably more performant. </p>
<p>Its also the approach taken by the majority of go developers, so you'd benefit from reading their code and incorporating it into your own. For example, you could use any of the middleware defined <a href="https://github.com/nindalf/linkto/blob/master/middleware.go" rel="nofollow">here</a> if you used <code>http.HandlerFunc</code> in your code. Choosing the popular approach makes a lot of sense when you're starting out. If you were a newbie Ruby dev wanting to make a website, its best to go with Rails or Sinatra.</p>
<p>On a side note, you did a disservice to the other people in this thread by misquoting them and being generally offensive. Learn to act with a little decency or go elsewhere.</p></pre>anonxgh: <pre><blockquote>
<p>I don't know what your problem with gorilla/mux is</p>
</blockquote>
<p>I don't have problems with gorilla. But its use will not automatically make your code beautiful, idiomatic, and maintainable.</p>
<blockquote>
<p>For example, you could use any of the middleware defined here</p>
<blockquote>
<p>URL shortener in 300 lines of Go</p>
</blockquote>
</blockquote>
<p>Great. But if you're going to evolve the project what will you end-up with? Framework. Won't you? Even if you're going to call it toolkit, a set of helper packages or whatever.</p>
<blockquote>
<p>other people in this thread by misquoting them</p>
</blockquote>
<p>Who said you those were quotes (or misquotes) of people in this thread? </p>
<p>P.S.: Pay attention to the fact nobody in this thread said something like "in my opinion Go doesn't need frameworks". Instead all comments start with "as gophers say", "as others mentioned", "as I've once read". Everybody read it somewhere. But few know why they "don't like frameworks". I would understand if there was clear criteria, e.g. heavy use of <code>reflect</code>, lack of customizability or incompatibility with the standard library. But it is religion when "framework" is bad (because a guy from Go team tweeted that), but framework renamed to toolkit is OK.</p></pre>dazzford: <pre><p>I would recommend not using any framework.
Everything you are mentioned can be taken care of by the std libs.</p>
<p>Is there some reason you are migrating?</p>
<p>If the goal is learning go, then learn the std libs, not some framework.</p></pre>_kobra: <pre><p>I am migrating mainly for better performance. </p></pre>_kobra: <pre><p>Thanks everyone. The conclusion I have drawn from this thread is to use the packages that best suits my requirements and not a full stack framework. I will post the packages I am planning to use after doing some research.</p></pre>YuryOdin: <pre><p>You can look to <a href="https://github.com/astaxie/beego" rel="nofollow">https://github.com/astaxie/beego</a> it's the most biggest framework...but consider write with microframeworks with other packages.</p></pre>_kobra: <pre><p>I did consider Beego, but the problem is it's ORM does not support all Postgres data types. </p></pre>bmurphy1976: <pre><p>What orm does? Postgres has a lot of wacky data types. I'd be shocked if any orm supported them all. What specifically is missing that you need?</p></pre>_kobra: <pre><p>I need inet, array and json. </p></pre>
