why not a golang WSGI implementation

WSGI protocol is specific to Python¹. With Go you have three options (actually, four, but plain CGI should supposedly be not considered for moderate to high load setups):

  • Built-in HTTP serving facilities of Go's standard library.

    In this case your app is a standalone server. This might be the simplest setup but it might have the following problems:

    • To run your app with downgraded privileges (you have to do this) on a privileged port number (below 1024, and 80 is in this range) you'll need to use a specialized wrapper or POSIX capabilities.
    • To provide for graceful redeployments without losing connections, you'll need another wrapper (like goagain).
  • Same as above, but behind a reverse HTTP proxy in the form of a web server.

    Mostly removes the problems of the standalone variant but still have the overhead of passing full HTTP traffic back and forth.

  • FastCGI via a suitable webserver. Nginx and Apache (and numerous others) are okay with this. FCGI client implementation is available in the Go standard library.

    In addition to not having the problems of the standalone setup, implements a more efficient data exchange protocol. Another bonus is that your Go server might communicate with the front-end web server using Unix pipes which have less transmission cost than TCP sockets involved in the reverse HTTP proxy variant.

So, if your setup currently uses WSGI, I'd say go with FCGI.

¹ As several commenters pointed out, strictly speaking, this is not quite correct: WSGI allows decoupling a web-serving application written in any language from a web server or an application server (connected, in turn, to a web server).
In order for this to happen, both parties must speak the same protocol, WSGI, which is language-agnostic. Still, it appears that most software not written in Python would either use HTTP or FastCGI to communicate with the front-end server.


Updated in 2020-11-19

As Andrea Citrolo correctly points out in their comment, with presently-ubiquitous containerization, when you have multple replicas of the same service deployed, and need to have load balancing over them, using plain HTTP is usually the only way to go.

I would also add that should you intend to expose your program written in Go to the internet (which is fine), you should read this.


There is a Go WSGI server here:

http://bitbucket.org/classroomsystems/wsgi

However, its intention is not to run Python servers faster – it runs a single CPython interpreter with a GIL. I wrote it to facilitate a smooth transition for my customers while our product is being moved from Python to Go.


While Go may not support the WSGI protocol per se, uWSGI, which is a pretty popular WSGI server has support for Go. Currently it looks like support is limited and not updated often, but it may be something to look into.

By default the uWSGI Go plugin supports the http.DefaultServeMux handler, so if your app is already based on it, running it in uWSGI should be extremely simple.

The following example is adapted from the uWSGI docs:

package main

import (
    "uwsgi"
    "net/http"
    "fmt"
)

func helloHandler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "<h1>Hello, World!</h1>")
}

func main() {
    http.HandleFunc("/hello/", helloHandler)
    uwsgi.Run()
}

Tags:

Wsgi

Go