WSGI Middleare is cool

Sure, there are lots of potential nitpicks that you can have with WSGI and WSGI middleware — mostly because the CGI spec on which WSGI is based is getting a bit long in the tooth — but I think those who get worked up about that kind of thing are missing the point.

WSGI provides a known, standard, working way to create reusable components of functionality which are coupled only to a published specification, not to your code. It’s the same reason that HTTP was so successful in the first place, you can build stuff without knowing exactly how it will be used later.

A perfect example of this is the new repoze.squeeze middleware that was released a couple of days ago.

It uses statistical analysis to decide how to best join and compress stylesheets and javascript resources based on actual usage.

Sure you could do this same thing with Django middleware, but if you use WSGI then Zope, Django, TurboGears, Plone, and any other WSGI compliant app can just use it without having to worry about this stuff inside the app itself.

BTW, they also released repoze.bitbit

which automatically re-sizes images before sending them out. When coupled with a good caching proxy server this makes it very easy to let people link to any-sized version of any of the images in your library. While i don’t think it’s as widely useful as repoze.squeeze, it too provides an example of something that can just sit there transparently helping you, and it exemplifies a kind of very loose coupling that is a mark of “true middleware.”

There’s another kind of middleware which does stuff that’s “required” for your app to work properly, and I agree that it’s probably best to call this something else, since it’s not transparent, but I think it too has a wide variety of uses, but that’s a blog post for another day.

5 Responses to “WSGI Middleare is cool”


  1. I got used to WSGI when I wanted to write CGI scripts that could be run with FastCGI easily (or mod_wsgi). And really, this is very easy with WSGI.

    The second thing that bought me into WSGI is that I was able to use Beaker a homegrown identity framework for TG1 while keeping the all the rest.

    So WSGI is no silver bullet but comes handy in a lot of situations.

  2. As I’ve been saying to anyone who will listen for the last 2 years:

    Yes, it’s great that we have a standard, but dear $DIETY, does it have to be this once?

    It’s all fine & good to talk about the benefits of reusable WSGI components. However, as someone trying to *author* such components, or modify existing ones, WSGI sucks.

  3. Pete,

    I know that WSGI isn’t perfect, I think the start_response callable was likely a mistake, as was the total dependence on the CGI spec. Hopefully we can put together a WSGI 2.0 spec which handles the issues that exist with the current one.

    But, I also think that WebOb makes working with the current WSGI spec a lot easier than it has been in the past, and I’d definitely support moving WebOb into the standard library in the next python version. I wonder if Guido has considered that…

    –Mark

  4. Not to go too far off your main point, but the similarities between WSGI and CGI are not that onerous. By far the larger problem is packaging–we, the industry as a whole, have a long history of distributing standalone packages, or at worst minimizing them to a handful. Heavy use of WSGI requires a whole set of new techniques to discover, identify, collect, install, version-control (both within and between dependencies), compile, build, configure, and test large numbers of disparate components. And Python’s tools for that are…still maturing.

  5. Well, the character encoding thing is a problem, as is the fact that you can’t tell the difference between a urlencoded slash and a plain old /.

    But I agree that having better dependency management and installation tools is critical for the kind of world of reusable components that I think we should be fostering. And this is exactly what linux distributions are good at — they gather hundreds of packages with lots of different versions test them, and make them work together well. dpkg, and other formats have proved themselves in that world, but eggs and the current sdist format have not lived up to that standard in python world.

    Hopefully there’s enough energy on that subject at the moment so that things get sorted out. (See my last distutils post).

Comments are currently closed.