24

We have concurrent issues in Python. These WSGI Servers just do not work that wonderful. I have a look around, get nothing like a Golang written WSGI Server with its goroutines.

Any reasons?

fengsp
  • 1,035
  • 1
  • 11
  • 19

3 Answers3

37

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.

kostix
  • 51,517
  • 14
  • 93
  • 176
  • ++ for a useful response that goes beyond the question as posed. – twotwotwo Dec 26 '13 at 01:58
  • 1
    Have you based that advice on benchmarks? My guess would be that the built-in approach (via goagain) would outperform FastCGI easily - but I'd prefer to see the numbers before deciding. On one site, Go HTTP is the current leader for one particular benchmark (http://www.techempower.com/benchmarks/), having recently pipped ahead of the JVM offerings. – Rick-777 Dec 26 '13 at 19:16
  • 1
    @Rick-777, no, unfortunately I have no hard data to back my claims. My remark about a more efficient data exchange protocol was about comparing `FastCGI` to `HTTP` reverse proxying -- I agree with you on that the standalone server should be the fastest soultion of all. – kostix Dec 29 '13 at 13:40
  • 1
    From : http://wsgi.tutorial.codepoint.net/ > WSGI[1] is not a server, a python module, a framework, an API or any kind of software. It is just an interface specification by which server and application communicate. Both server and application interface sides are specified in the PEP 3333. If an application (or framework or toolkit) is written to the WSGI spec then it will run on any server written to that spec. – programaths Aug 14 '16 at 08:54
  • @programath, sure, but I've yet to find in the wild any useful piece of software running under WSGI and not having been written in Python. ;-) I assumed the OP's first encounter with web programming was through Python and so they just got fixated on that particular bit of technology, and that's why my explanations. – kostix Aug 14 '16 at 13:43
  • @kostix `WSGI protocol is specific to Python` could be reworded in `WSGI originated from the need to decouple server from application, problem often encountered in Python world`. – programaths Aug 14 '16 at 13:47
  • 1
    @kostix it is usefull to point out that if the objective is to run several replicas of the go service through containerization (as almost anyone is likely to do these days) option two is the correct way to go. – Andrea Citrolo Nov 19 '20 at 16:32
3

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()
}
korylprince
  • 2,969
  • 1
  • 18
  • 27
  • 1
    uwsgi is not what you believe it to be. I'm surprised people upvoted this. uwsgi is a multipurpose tool to run multiple scripting languages or compiled languages. It has little to do with the question at hand. The example you posted would run a go program using uwsgi. So instead of `http.ListenAndServe()` you have uwsgi.Run(). uwsgi is like an adapter that lets you plug in different languages. WSGI is a protocol. uwsgi only shares the letters "wsgi". It's like saying Bananas and Nanas are the same and if you need a nanny you should buy a banana. Doesn't mix –  Jan 18 '16 at 12:38
  • @dalu Rereading the question now 1.5 years later, I do see that I misunderstood the question. I do know what uwsgi is, and I see now the OP was actually asking if there was a WSGI server written in Go (that would run Python WSGI applications.) – korylprince Jan 18 '16 at 18:33
3

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.

MicahStetson
  • 602
  • 4
  • 6