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
andApache
(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.