<p>Im looking for a productive and fast Web Framework for building microservices. What you suggest?</p>
<hr/>**评论：**<br/><br/>PsyWolf: <pre><p>The standard advice we give to newcomers is... don't. Start with the standard library's net/http. It's way better than the equivalent in most other languages. You'll be surprised how far that will get you. If and when you find you have a specific need that isn't solved adaquately by the stdlib (say advanced muxing), find a specific library that solves that specific problem (like <a href="https://github.com/gorilla/mux" rel="nofollow">gorilla/mux</a>). </p>
<p>Frameworks can be nice, but they come at a cost. Your code often stops playing as nicely with libraries outside of the framework, you pull in lots of dependencies you don't actually need, you may even end up writing boilerplate to support features you don't care about. By starting with just the standard lib and only reaching for 3rd party libraries to solve specific problems, you'll keep your code lean, mean, and flexible.</p>
<p>When you do need some 3rd party code, <a href="https://github.com/avelino/awesome-go/blob/master/README.md#web-frameworks" rel="nofollow">https://github.com/avelino/awesome-go/blob/master/README.md#web-frameworks</a> is a great place to look. </p></pre>ChristophBerger: <pre><blockquote>
<p>You'll surprised how far that will get you.</p>
</blockquote>
<p>I second that. It is astonishingly simple to use a TCP connection as an <code>io.ReadWriter</code>. Even sending and receiving native Go data types over the net is a snap with <code>encoding/gob</code>. (Shameless plug - I blogged about this <a href="https://appliedgo.net/networking" rel="nofollow">recently</a>.)</p></pre>sybrandy: <pre><p>Similar to gorilla/mux is httprouter, which I personally like and use at work. Regardless, simpler is better. Just get what you need when you need it. I personally find full-blown frameworks to be overkill in most cases.</p></pre>jiimji: <pre><p>what does a productive framework for building microservices do? people who ask these questions again and again never bother describing what they actually want.</p></pre>trontybullpit: <pre><p>I hear your response a lot in regards to the common microservice framework question, and I think it's a suitable question because the benefits are not always obvious.</p>
<p><strong>The advantages:</strong></p>
<ul>
<li><p>It's often about organisation and standardisation rather than code functionality. It's a good idea to follow a standard when creating anything in the engineering discipline and a framework is an excellent way to provide that.</p></li>
<li><p>It also often provides the benefit of a large eco system of compatible libraries and problem solving patterns.</p></li>
<li><p>It enables newbies to get up and running quickly, something that is often attributed with increasing immediate reward and keeping people interested.</p></li>
<li><p>It provides a pattern that is (hopefully if it's well written) a quality design which means you don't need to get burnt writing the solution several times.</p></li>
</ul>
<p><strong>The disadvantages:</strong></p>
<ul>
<li><p>It can hide the methodology of what is actually being performed behind "magic" api calls.</p></li>
<li><p>It may not be fit for purpose</p></li>
<li><p>It may actually be a bad design which leads to a poor solution</p></li>
</ul>
<p>I think the standard library is incredible and a framework is not <em>required</em> in Go as much as in other languages such as Python and Ruby.</p>
<p>I've personally used GoKit before and it helped me understand code architecture solutions that are well suited to go. I think it's a very good solution availab.e</p>
<p>Note, for newbies regarding GoKit. It is beneficial incredibly beneficial for larger projects, as it provides a common compatible pattern for services written. I newbies should at least write a project that follows the GoKit pattern prior to using it so they can understand what it is trying to do. It's worth noting that the first tutorials in go-kit are in my opinion perfect.</p>
<p>For a project with only a few services, it could be considered overkill as it doesn't add features as much as enforce a implementation style. This is generally because the Go standard library comes with so much out of the box already.</p>
<p>Gizmo is a similar project, but it was focused heavily on web abstractions without the additional layer of abstraction that GoKit provides.</p>
<p>As I prefer to write my projects with multiple transport layers and interfaces (command line, grpc, http, distributed messaging), I lean towards the GoKit design.</p>
<p>The use of reflection in GoKit has been the cause for concern for some people (including myself) that has been documented and discussed (with the author <a href="/u/peterbourgon" rel="nofollow">Peter Bourgon</a> weighing in). In my opinion, the use of interface is simply unavoidable and provides minimal performance impact for the vast majority of uses. However the additional run-time checking required in my opinion does not provide a sufficient benefit over the code reduction. This is highly dependent on each use case and GoKit doesn't prevent you bypassing the use of <code>interface{}</code> if that appears to be the bottle neck. Additionally, if the reflection is the cause of a bottle neck, it is likely your request is sufficiently large, or is doing very little.</p>
<p>Unfortunately the only alternative is manually writing code following convention - which is more fragile as it is not enforced by the compiler/framework.</p></pre>peterbourgon: <pre><p>To clarify, type assertion of interface{} to a concrete request type costs order of 100 nanoseconds. It's not a bottleneck or even worth talking about.</p></pre>trontybullpit: <pre><p>Thanks for the clarification :)</p></pre>jiimji: <pre><blockquote>
<p>or even worth talking about</p>
</blockquote>
<p>it is if one values type safety.</p></pre>peterbourgon: <pre><p>There are obviously type safety concerns, but, at least in Go kit, they're pretty tightly encapsulated, and fully verifiable with quite coarse wiring unit tests.</p></pre>tute666: <pre><p>go-kit microservices
gin or chi for web</p></pre>ChristophBerger: <pre><p>To extend this list - what I often see in recommendations is</p>
<p>go-kit or micro<br/>
gin or chi or echo</p></pre>yami_odymel: <pre><p>I personally don't suggest to use go-kit because you have to write a lot of the duplicated code and interfaces with it.</p>
<p>I'd suggest to have a try with gRPC, with Protocol Buffers, you can share the schemas between microservices without the pain.</p></pre>gsquire: <pre><p>Anything but <a href="https://github.com/kataras/iris" rel="nofollow">https://github.com/kataras/iris</a></p></pre>andre_borges: <pre><p>The documentation is not updated</p></pre>broady: <pre><p>That's pretty unconstructive. Do you have recommendations?</p>
<p>I'd take a look at goa. I haven't used it but hear good things.</p></pre>gsquire: <pre><p>I suppose I said this due to the licensing negligence by the core author. <a href="https://github.com/julienschmidt/httprouter/issues/148" rel="nofollow">https://github.com/julienschmidt/httprouter/issues/148</a></p>
<p>But there are plenty of good frameworks like echo or gin. I personally like using the standard library with middleware I need in between.</p></pre>iris-go: <pre><p>Good luck on putting deflamation on Iris (again).</p>
<p>LICENSE for the edited httprouter: <a href="https://github.com/kataras/iris/blob/v6/adaptors/httprouter/LICENSE#L24" rel="nofollow">https://github.com/kataras/iris/blob/v6/adaptors/httprouter/LICENSE#L24</a> and if you look inside folders everywhere I use a third-party package I write it on a LICENSE file and we have already spoke with the julien the next day of this issue and it was solved, ask him. Stop putting deflamation about Iris' source code. Compare its speed, its features with other web frameworks, don't try to destroy the trust that community gave to Iris by spamming links form Iris' first days, this is not smart and certainly not a normal behavior for a developer to another.</p></pre>shovelpost: <pre><blockquote>
<p>not a normal behavior for a developer to another.</p>
</blockquote>
<p>Get out kataras.</p></pre>trontybullpit: <pre><p>kataras, I think you certainly put in a lot of effort and are understandably emotionally involved in the project. I respect the amount of hours that you've put into the project.</p>
<p>I think you'd see a more positive response from the community if you addressed the concerns regarding your attribution of code and use of git.</p>
<p>It appears you've made some improvements along the way - but I note that there is still only 1 contributor to the project.</p>
<p>You're not going to make progress in the community by constant hostility towards negative reflections of the project. Perhaps some of this is due to English being a second language.</p>
<p>I think a good API is difficult to design, and I know I have trouble designing one that feels really nice. Having said that, I don't think the API intuitive and I hope this is something you continue to work on.</p>
<p>I think there is unnecessary promoting of the speed of the project. Iris is certainly not the only framework that is guilty of this. It is unlikely someone using Iris will be for the routing alone, as they'd be better served by using that library directly (httprouter/mux).</p>
<p>There is a place in the community for a project that provides a large framework by combining the great features of a number of libraries around the community into a single eco-system and hope you continue to work on your goal and seek feedback and improvement from the community.</p></pre>tmornini: <pre><p>What do you mean by web framework for microservices?</p>
<p>Microservices typically indicate an API first design to build web applications atop.</p>
<p>A web framework typically indicates a server rendered HTML first design.</p>
<p>Just trying to ascertain what you're looking for.</p></pre>rokjoana: <pre><p>Give go-micro a try :) <a href="https://micro.mu/blog/2016/03/28/go-micro.html" rel="nofollow">https://micro.mu/blog/2016/03/28/go-micro.html</a></p></pre>
