5 ms·

I was always taught never to write my own web server since something like Apache has been tested on millions of sites, and you have security experts designing i

I was always taught never to write my own web server since something like Apache has been tested on millions of sites, and you have security experts designing it. Does writing your own server in Go kind of violate this idea? Are you opening yourself up to re-inventing a web server and repeating decades of mistakes something like Apache has already figured out and fixed?

eckyptang 14y ago
You are correct - you should never write your own web server. In this case, you're not writing your own web server. There is one provided with the standard library which will be embedded into your binary. You are writing a bunch of handlers (as you would with Apache) and plugging them into the compiled in web server from the standard library. For network servers, there is standard library support for SMTP, HTTP, normal stream based text protocols etc as well as serialization formatters and parsers for JSON, XML, HTML etc. You should never have to re-invent the wheel.
exch 14y ago
Writing a (web)server in Go is not so much about reinventing the wheel, as it is about slapping together the existing building blocks into a server specifically tailored to your application. These building blocks are very complete and are all available in the standard library. This means they are tested, debugged, tested again and have become pretty damn robust. The point about Apache/NGinx being well established and battle hardened still stands, but Go's library is quickly following suit. What Go offers over the others in this respect, is that you do not have to settle for a monolithic one-size-fits-all package. The code you write in Go does one thing (serve your application) and does it well without any compromises.
ehutch79 14y ago
It should also be noted, that you're not being encourage to serve static media with your go app. it's more like fastcgi or wsgi. you would have apache or nginx sitting in front of your app listening only on localhost serving dynamic pages only.
tptacek 14y ago
That's why you front-end app servers with reverse proxies like nginx and Varnish. In practical reality, most major sites run applications out of app servers that are less well tested than Apache. This is not a real objection.

eckyptang 14y ago

You are correct - you should never write your own web server. In this case, you're not writing your own web server. There is one provided with the standard library which will be embedded into your binary. You are writing a bunch of handlers (as you would with Apache) and plugging them into the compiled in web server from the standard library. For network servers, there is standard library support for SMTP, HTTP, normal stream based text protocols etc as well as serialization formatters and parsers for JSON, XML, HTML etc. You should never have to re-invent the wheel.

exch 14y ago

Writing a (web)server in Go is not so much about reinventing the wheel, as it is about slapping together the existing building blocks into a server specifically tailored to your application. These building blocks are very complete and are all available in the standard library. This means they are tested, debugged, tested again and have become pretty damn robust. The point about Apache/NGinx being well established and battle hardened still stands, but Go's library is quickly following suit. What Go offers over the others in this respect, is that you do not have to settle for a monolithic one-size-fits-all package. The code you write in Go does one thing (serve your application) and does it well without any compromises.

ehutch79 14y ago

It should also be noted, that you're not being encourage to serve static media with your go app. it's more like fastcgi or wsgi. you would have apache or nginx sitting in front of your app listening only on localhost serving dynamic pages only.

tptacek 14y ago

That's why you front-end app servers with reverse proxies like nginx and Varnish. In practical reality, most major sites run applications out of app servers that are less well tested than Apache. This is not a real objection.