3 ms·

The compiled output will contain your network server. you run the process and it listens on a socket. It is pretty straightforward. Using HTTP as an example, ea

The compiled output will contain your network server. you run the process and it listens on a socket. It is pretty straightforward. Using HTTP as an example, each request will run in a goroutine which is somewhere between a thread and a coroutine. It is extremely fast. The main risk is process failure which is very rare but can be mitigated via putting a front end balancer such as nginx or apache mod_proxy. Process recovery and spawning can be managed by another tool such as supervisord. However, you can run a process happily from init if you desire.

tocomment 14y ago
Thanks! That's exactly what I was trying to figure out. You're a gem. So is there anywhere I can see an example of code that runs a server like this?
- eckyptang 14y ago
  From the tour - I've added comments for clarity: // this defines the entry point package main // import formatting and HTTP server packages import ( "fmt" "net/http" ) // This is your HTTP Server instance type Hello struct{} // This is a method on your HTTP server instance that sends hello for all requests func (h Hello) ServeHTTP( w http.ResponseWriter, r *http.Request) { fmt.Fprint(w, "Hello!") } // this is your entry point func main() { // create a new HTTP Server instance var h Hello // tell the runtime to serve it http.ListenAndServe("localhost:4000",h) }
tocomment 14y ago
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.

tocomment 14y ago

Thanks! That's exactly what I was trying to figure out. You're a gem. So is there anywhere I can see an example of code that runs a server like this?

eckyptang 14y ago
From the tour - I've added comments for clarity: // this defines the entry point package main // import formatting and HTTP server packages import ( "fmt" "net/http" ) // This is your HTTP Server instance type Hello struct{} // This is a method on your HTTP server instance that sends hello for all requests func (h Hello) ServeHTTP( w http.ResponseWriter, r *http.Request) { fmt.Fprint(w, "Hello!") } // this is your entry point func main() { // create a new HTTP Server instance var h Hello // tell the runtime to serve it http.ListenAndServe("localhost:4000",h) }

tocomment 14y ago

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.