Most popular/used Golang Web Framework?

polaris · · 479 次点击    
这是一个分享于 的资源,其中的信息可能已经有所发展或是发生改变。
<p>I&#39;m looking into some Golang web frameworks (specifically Beego, Echo, Gin, Iris, and Revel). I&#39;m wondering which of these, if any, is the most popular or widely used.</p> <p>I&#39;ve also seen people mention that Go frameworks aren&#39;t necessary, which I also could see. The standard Http library is quite robust (or using something like Gorilla).</p> <p>Just curious about this communities take.</p> <hr/>**评论:**<br/><br/>mixedCase_: <pre><p>Standard lib with a third party router.</p> <p>I like <a href="https://github.com/pressly/chi">Chi</a>. It&#39;s idiomatic and fast as hell.</p> <p>I also use some of Gorilla&#39;s middleware.</p></pre>diegobernardes: <pre><p>Chi is amazing, i&#39;m using in all my projects.</p></pre>lwcd: <pre><p>Seconded. Chi + net/http is pretty much all you need</p></pre>hoffentlich: <pre><p>Not Iris, really no. Between the ones you listed, Gin and Echo are the most popular and used in production, if any framework is being used at all. Gin has proven itself. I hear Echo is production ready as well but I only played with it a bit. Gin may have a bit more than Echo in terms of middlewares and such. Not sure.</p> <p>/edit ah and also gorilla is quite popular with those who don&#39;t like using a framework and instead prefer to integrate different parts with the http module from the standard lib, which is a good approach. Depends on your needs.</p></pre>BubuX: <pre><p>context about Iris: <a href="http://www.florinpatan.ro/2016/10/why-you-should-not-use-iris-for-your-go.html">http://www.florinpatan.ro/2016/10/why-you-should-not-use-iris-for-your-go.html</a></p></pre>bkeroack: <pre><p><code>stdlib</code></p> <p>Although at this point I&#39;m starting to advocate implementing everything in GRPC natively because then you can autogenerate a JSON HTTP1.1-compliant server <strong>AND</strong> api docs (Swagger) <a href="https://github.com/grpc-ecosystem/grpc-gateway">at the same time</a>.</p></pre>iends: <pre><p>This is an interesting idea, is there somewhere I can read more other than the linked github project?</p></pre>bkeroack: <pre><p><a href="http://www.grpc.io" rel="nofollow">http://www.grpc.io</a> mainly. You can also Google for a bunch of talks about GRPC and Go.</p> <p>With GRPC you define your service in a protobuf file with strongly-typed inputs and outputs. Native GRPC clients use that, while the linked project autogenerates a JSON API server for legacy HTTP 1.1 clients.</p></pre>yami_odymel: <pre><p>Don&#39;t use gRPC of your client is a browser. It&#39;s hard to communicate with a browser via Protobuf. Yes, you can generate the JSON API but it&#39;s a mess.</p></pre>darkmagician2: <pre><p>Not anymore. <a href="https://spatialos.improbable.io/games/grpc-web-moving-past-restjson-towards-type-safe-web-apis" rel="nofollow">https://spatialos.improbable.io/games/grpc-web-moving-past-restjson-towards-type-safe-web-apis</a></p></pre>goomba_gibbon: <pre><p>May I ask a bit more about what it&#39;s for? Default response is &#34;standard library&#34; (for good reasons) but it will definitely depend on your use-case.</p> <p>edit: I also hear good things about buffalo but I haven&#39;t tried it personally - <a href="http://gobuffalo.io/docs/getting-started" rel="nofollow">http://gobuffalo.io/docs/getting-started</a></p></pre>sdomino: <pre><p>Really I&#39;m just trying to get a sense of whether or not there is something other than the standard lib that is emerging as a popular web framework (Ruby has Rails, Elixir has Phoenix, etc.)</p> <p>edit: I&#39;m writing a high level &#34;how to&#34; article for one of the Golang frameworks that Nanobox supports (<a href="https://guides.nanobox.io/golang/" rel="nofollow">https://guides.nanobox.io/golang/</a>), and I wanted to get an idea of whether or not there was a framework that would benefit most from such an article (help the most people).</p></pre>shovelpost: <pre><p>The community is trying its best to avoid falling into the framework pitfall.</p></pre>aboukirev: <pre><p>The following is not targeted at you but at &#34;the community&#34;.</p> <p>Once to get to a sizable Web application where a you need to cover serving static files, content negotiation, chunking (download, upload), processing OPTIONS, proper caching headers, real IP behind proxy, authentication, caching templates, form binding, etc. you&#39;ll need an existing 3rd party framework or roll your own (you&#39;ll want to reuse that in other projects, right?). Either way, framework it is. If you want to call it a collection of libraries, go ahead. IMO, there is nothing wrong with using a framework so long as it works and is flexible enough.</p> <p>Want a UI? Is OpenGL enough? Sure you can do everything with it. No UI frameworks. /sarcasm</p></pre>: <pre><p>[deleted]</p></pre>shovelpost: <pre><p>If possible please remove Iris from the Nanobox support for <a href="http://www.florinpatan.ro/2016/10/why-you-should-not-use-iris-for-your-go.html">these reasons</a>.</p></pre>kaeshiwaza: <pre><p>I wonder if gorilla session is still recommended lib since 1.7+ ? Or maybe <a href="https://github.com/alexedwards/scs" rel="nofollow">https://github.com/alexedwards/scs</a> ?</p></pre>PaluMacil: <pre><p>My impression is Gorilla toolkit libraries (especially mux) or standard library are the most popular choices since Go devs seem to avoid heavy or complex full frameworks. Gin seems to be next. The others you mentioned are less common in production, but Go is just built to make great web api an easy accomplishment. Chi seems to have good momentum but I personally don&#39;t know anyone using it in their commercial work. I&#39;ll hopefully get around to trying it soon.</p></pre>andradei: <pre><p>Buffalo is pretty good too, but I&#39;m not sure whether it is production-ready though the project is very active.</p></pre>

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

479 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传