Stick to WSGI

Recently there was an unusual amount of attention and discussion about WSGI and how something needs to be done about it (or not).

Some people propose a complete replacement that “hopefully will replace WSGI one day”. Others propose to add more specs to standardize how pluggable services (like web sessions) interoperate with WSGI apps. Overall the consensus seems to be that while WSGI does solve the problem it was supposed to solve, but it does that in a suboptimal way. In particular, writing fully compliant applications, servers and middleware is very hard.

So, apparently, we need another spec that addresses the same problem as WSGI but does it in a cleaner way. To make it practical, it is proposed that we can use adapters between these two specs, so apps written to either one can work in the same environment, calling each other etc.

I don’t think any of that is a good idea. First of all, if we have a WSGI spec which has its problems but is not going anywhere, adding another, simple and nice spec will not make things simpler overall. When you add something without taking anything out total complexity increases. Even moreso, if you consider the need for adapters between the two, the need to detect when the adapters are necessary etc.

If you find writing correct WSGI apps hard, you’re doing it wrong

The other big reason, is that WSGI does work. It’s non-trivial to write WSGI software with no library support, but anyone who still does that in 2011 is plain stupid and we should not take that stubbon, opinionated-but-not-quite-competent type of programmer into account. Surely we should not create new specs just because someone keeps shooting themselves in the foot after ample warnings.

If you are using WebOb or its equivalent, writing WSGI apps, middleware and even servers is not hard. There’s very little you need to know about WSGI and its quirks because WebOb provides enough isolation, that you can think in terms of HTTP requests and responses and not worry about the WSGI stuff. Yet, you don’t need to depart from WSGI, you can still provide and consume WSGI interfaces all the way down in your stack.

I want to stress that I am not saying that WebOb replaces the WSGI interface with its own calling conventions that you should use instead. I’m saying that you can work with raw WSGI without being exposed to its quirkiness. I’ll show this with a couple examples and in all of them we will be writing valid WSGI applications without ever touching environ, start_response or app_iter.

Let’s do an app first:

@wapp
def app(req):
    return Response("Hello, %s!" % req.GET.get('name', 'Stranger'))

Seems easy enough, and trust me, this is not a misleading example, things do not get any more complicated when you do more than that.

Do you want middleware with that?

@wapp_mw
def middleware(req, app):
    resp = req.get_response(app)
    if resp.content_type == 'text/html':
        resp.ubody += '<h2>Middleware was here!'
    return resp    
    
wrapped_app = middleware(app)

That’s a valid WSGI middleware.

I anticipate that one of the objections to my claims will be that we are using a different calling signature which puts us in line with all those other solutions I discarded in the beginning of the article. This is incorrect. The applications do not provide or consume the (req->resp) interface , it’s an implementation detail completely incapsulated and hidden for every wrapped function (i.e. you cannot call app(req)). We do not ever use those functions in any way other than any other WSGI app — they are black boxes providing the WSGI interface.

One might say that this is similar to the @lighten and other wrappers that map from one spec to another, but that is also incorrect. We do not have any spec. We never do any adaptation. All we have are WSGI apps that we implement without dirtying our hands by working with it directly.

Once you accept that, you will see that what happened there is that we have abstracted the WSGI away and now WSGI is just some interface for plugging web applications together, we don’t ever see what that interface is and don’t really need to know what it is, and therefore absolutely don’t care what it is. We are just happy that it exists, that there’s just one and that we can use any of the existing WSGI apps, middleware and servers without any adapters. There’s simply no need for a “better WSGI”.

See? Implementing valid WSGI software is not hard and is not a problem, and if you still think otherwise you need to go back and start at the top.

WSGI spec still has problems though

On the other hand, creating a library that hides all the quirks is not easy and I wish WSGI spec was different, but if you create yet another spec, you will not make my job easier (or that of anyone else who works on similar libraries).

So, if the problems of WSGI are taken care of (in the form of libraries), exactly what problem all these WSGI alternatives are solving?

There’s an argument that if eventually a new standard completely replaced WSGI it would be a good thing. First of all, remember that there’s very little need to do this. Another thing is that to make adoption happen, it is very likely for this new spec will have to share some things with WSGI inheriting some of the problems. Also, don’t be naive, complete replacement of WSGI will not happen.

I’ll repeat: the only benefit a new spec can provide is to make the life easier for those who have to work with WSGI directly. The only kind of such a new spec I would support is a subset of WSGI, a WSGI-properly-light. A spec that is stricter than WSGI, and thus any app or server that conforms to it is a valid WSGI app without any adapters. No changes to calling signature, no “solutions” to WSGI problems, just outlawing some bad practices that are acceptable under PEP-333/3333.

Let’s look at an analogy. HTTP is not a very good protocol or standard. It serves us amazingly well, but it’s not very good. If you think we can one day deprecate it in favor of some HTTP 2 you must be on drugs. We are stuck with it and we are doing the best we can with it. There are a number of areas in the spec that are universally not used. Weak ETags for example, or multiline headers. If one were to update the HTTP spec it would be by throwing those parts away, to mirror the real-world usage. If we are to do anything about the WSGI, it is to do a similar thing and say that the apps should not use write = start_response(..) etc. (the servers still have to support that for a long time though). Or, we can also do nothing which works just fine for HTTP and was working for WSGI so far.

Also, async WSGI

WSGI was not designed for this, don’t torture it and go for a separate spec for async apps. It’s not like you even need to pass both through the same dispatching or middleware anyway. A tiny spec just for async / push web apps is the right thing to do.

TLDR: we need protocols to gain interoperability. Once interop is there, a better protocol solves nothing (for most parties). So yeah, WSGI is ugly in many ways, but you better stick to it.