What's the difference between net/http and all the other things (eg echo, fasthttp, etc) for web development?

<p>I&#39;m new to Go, and considering dropping python for it on my upcoming project. I&#39;m getting a bit confused trying to place the different components, and would appreciate some help figuring it out.</p> <p>On benchmarks like <a href="https://www.techempower.com/benchmarks/#section=data-r13&amp;hw=ph&amp;test=db&amp;l=4ft5hb">https://www.techempower.com/benchmarks/#section=data-r13&amp;hw=ph&amp;test=db&amp;l=4ft5hb</a>, the &#39;top&#39; go framework tends to flip between echo-prefork and fashttp-&lt;somedb&gt;-prefork. I also hear people say that net/http is perfectly fast and fine.</p> <p>Is net/http something that&#39;s built into golang by the original developers? Is it enough to build the whole site from? </p> <p>What do echo/fasthttp do that net/http doesn&#39;t do? </p> <p>Are there other frameworks that do a much better job of helping you build a website instead of just looking fast on benchmarks?</p> <p>edit: Thanks for all the answers! The general gist I get is to not worry about frameworks yet and just go with net/http until it actually becomes an problem, which sounds like a good idea. </p> <hr/>**评论：**<br/><br/>bear1728: <pre><p>Yes, net/http is part of the standard library and was mainly written by Go devs. I don&#39;t know the exact history, but it&#39;s very possible there have been commits from people outside of Google as well.</p> <p>My opinion on benchmarks: unless you&#39;re running a very large site with a lot of visitors, or are extremely constrained in terms of resources, I don&#39;t think it&#39;s going to make a difference. Especially if your site uses a database like sqlite or postgres/mysql/etc. One reason I like Go is that the built in testing framework is pretty easy to use and test very small and different parts of a system. I just wish you could benchmark on the playground.</p> <p>You could build a great site without using other libraries/frameworks. But those other options do offer some helpful things. I started with <a href="https://github.com/zenazn/goji">goji</a> because it had the most example code that I could copy and paste. Now I use <a href="https://github.com/pressly/chi">chi</a>. The only real reason I use any framework is that I&#39;m too lazy to write a function to do dynamic routes, like &#34;/user/:id&#34;. Most frameworks/libraries I&#39;ve seen have ways to do this.</p></pre>carsncode: <pre><p>So does net/http if it&#39;s just a suffix. If you use a route with a trailing slash in the stock mux, anything starting with that path will go to that handler. So /user/ route with a getUser handler would send a request for /user/bear1738 to that handler, and you can easily grab the relevant part of the path.</p></pre>bear1728: <pre><p>Good point! I totally forgot to mention that.</p></pre>ZetaHunter: <pre><p>+1 for Chi, using it in several of my own pet projects currently.</p></pre>Hunterbunter: <pre><p>Thanks, I think I&#39;ll go for a net/http start and look into the features of the different frameworks a bit more. I may have been focusing too much on speed.</p></pre>comradeswitch: <pre><p>This is what I recommend and what I do, personally. It&#39;s tempting to go for the fastest or the most feature rich framework, most of the the time, your http.Server or Client implementation is not going to be a bottleneck. Premature optimization might not be the root of all evil but it can definitely lead to needless complexity and dependencies.</p> <p>Even if your http api is a bottleneck, there&#39;s almost always something that can be done in terms of design that will have a bigger impact. You can leave the serving of static files to something like nginx. A change to your api might allow for clients to make a few larger requests and/or cache response data. Templates can be pre-rendered partially or completely.</p> <p>But in any case, before you start thinking about that, profiling is the best first step.</p></pre>Veonik: <pre><p>I would recommend you not put the cart before the horse. Get a feel for the language, maybe decide to use a framework like echo, maybe not. Go tends to have a very rich standard library (of which <code>net/http</code> is a part of) but there is of course room for improvement, especially with a specific use-case in mind.</p> <p>Picking a library because it can serve a billion requests per second is perhaps the wrong approach-- are you likely to ever max out throughput to where these microbenchmarks matter?</p> <p>Better questions might be: What features does it have? Does it make developers more productive? Does it solve your problems? I see you&#39;re already thinking along these lines, so that&#39;s great.</p> <p>All that said, <code>net/http</code> is great and will very likely serve you well, especially starting out.</p></pre>Hunterbunter: <pre><p>I do expect concurrent use, and some of them will randomly be causing a lot of work to be done. I want to try to avoid slow down for everyone else while that&#39;s happening.</p> <p>As long as net/http does everything the frameworks do, I&#39;m happy giving that a go first.</p></pre>puffybunion: <pre><p>Don&#39;t worry about it. You&#39;re starting out, net/http is totally fine.</p></pre>drvd: <pre><blockquote> <p>What do echo/fasthttp do that net/http doesn&#39;t do?</p> </blockquote> <p>For fasthttp: Please note that fasthttpd does <strong>not</strong> implement full HTTP! It provides a strict subset of HTTP which often is enough for simple things and serving web browsers.</p> <p>And please do not look at such sort of &#34;benchmarks&#34; unless you are running Twitter or some realtime stock trading company.</p></pre>codesenberg: <pre><p>I&#39;d like to add that not only <strong>fasthttp</strong> doesn&#39;t follows all of the RFCs related to HTTP/1.1, but it also doesn&#39;t support HTTP/2.0.</p> <p>Still it&#39;s pretty useful, really fast and successfully used in production by <strong>VertaMedia</strong> serving up to 200K rps from more than 1.5M concurrent keep-alive connections per physical server( as cited in <a href="https://github.com/valyala/fasthttp/blob/master/README.md#fasthttp" rel="nofollow">README</a> ).</p></pre>Hunterbunter: <pre><p>Ah I didn&#39;t know that, thanks.</p> <p>The project I&#39;m going to build could be required to occasionally and dynamically do a lot of processing, so speed is kind of important. I wouldn&#39;t want it to grind to a halt randomly for clients. I was even considering C++ but development time is important too. Go&#39;s simplicity and speed is a big attractive thing right now.</p> <p>Otherwise I probably would have just stuck to python for the MVP since I know it a lot better.</p></pre>BraveNewCurrency: <pre><p>Note that you are talking between 100K to 200K requests per second. It&#39;s unlikely to make a real-world difference for several reasons:</p> <ul> <li>Your clients won&#39;t notice the difference between 0.01ms and 0.005ms. It will literally be lost in the noise of packet jitter.</li> <li>&#34;But I can save money by running on half the boxes&#34; I heard you say. Nope. In the short-term, you are not going to have 100K requests/second hitting your site, so your point is moot. By the time you DO get 100K rps (i.e. millions of users), it is likely you will be able to afford 2 boxes.</li> <li>Yes, 100K vs 200K is a 2x speed up. But if you start actually doing any work in your app (auth, etc), then your seedup will be a lot less than 2x. In fact, for many applications (such as resizing a jpeg), the contribution of the framework will be almost too small to measure.</li> </ul></pre>Hunterbunter: <pre><p>Would google/seo notice the speed difference and rank pages higher because of it? </p> <p>I know that might be a funny question but I&#39;ve heard that all things being equal the faster page gets the higher rank. I&#39;m not sure if there&#39;s a cutoff.</p></pre>BraveNewCurrency: <pre><blockquote> <p>Would google/seo notice the speed difference and rank pages higher because of it?</p> </blockquote> <p>Ha ha, really doubtful -- The speed rank was added because Humans don&#39;t like to wait for slow pages. Anything under 50ms is probably ranked the same. (See <a href="http://www.thesempost.com/how-page-speed-as-a-ranking-factor-works/" rel="nofollow">actual slide</a> from google presentation)</p> <p>Also, when you are talking about 0.01ms, the jitter from all the routers in between you and the server WILL dominate your measurements anyway.</p> <p>Just like the old joke &#34;I don&#39;t have to be faster than the bear, I only need to be faster than you&#34;, speed doesn&#39;t matter unless it serves a specific business purpose. If you spend time speeding up something users don&#39;t care about (or can&#39;t even measure), you&#39;ve wasted your time. Work on something user-visible to get the biggest bang for your buck.</p></pre>Hunterbunter: <pre><p>good advice, thanks</p></pre>jns111: <pre><p>net/http is perfect for whatever you want to build. It comes with http2 push support and websockets. On top of that you will have compatibility if you follow strictly the http.Handler pattern. But what about performance? Yes it&#39;s true, fasthttp and other frameworks/libraries achieve a lot more 200 OK responses, but what does it mean? Are you offering a ping service? In this case you should really consider one of these frameworks. But if for example you offer an api in most cases you will burn cpu and ram to marshal and unmarshal data, process stuff and wait for a database to answer your query. So in a realistic scenario you will not benefit much from using such fast library because your bottleneck will be other parts like the database.</p></pre>Hunterbunter: <pre><p>Thanks for your response, it&#39;s another +1 for net/http. The benchmarks I put in OP does supposedly test things like json creation, single/multi queries, random fortune cookie thing, and so on. </p></pre>smcquay: <pre><p>I have been writing Go professionally for three years. Services I have written have served billions upon billions of requests. I use net/http. </p></pre>Hunterbunter: <pre><p>cool an extra thumb up for net/http.</p></pre>itsmontoya: <pre><p>Just stick with stdlib. I&#39;ve done quite a bit of real world testing with the other libraries and didn&#39;t see any performance gains (in fact, I saw decreases when comparing against stdlib)</p></pre>