The various ways of writing a modern Python web app

January 26, 2011

As the flipside version of last entry, suppose that you want to write some sort of web thing in Python and you want to know what to use to do it. Broadly speaking, you have the following main options:

  • Write it as a straight CGI.

    This is probably the simplest approach for small stuff if you don't already have a WSGI server or a framework environment set up that you can just plug small applications into. Python's core library has plenty of batteries for this environment.

  • Write your own WSGI stack from the ground up.

    This will be a great learning experience and it's not that much work (the standard's CGI-based WSGI server is under a hundred lines of Python code, and the code works fine in production with a minor change to gracefully catch network write errors).

  • Write a WSGI app for an existing WSGI server environment.

    WSGI apps are good for straightforward things and WSGI is more flexible and less annoying than CGI, easier to plug into various setups, and performs (much) better under significant load. You might even be able to find some WSGI middleware that does stuff you want.

    (I don't know what WSGI server environment you should use. The extent of my knowledge is that the Django people recommend either mod_wsgi or flup, per here.)

  • Write an application for your favorite framework.

    This will be the easiest way to do significant work with forms, database tables, and so on, since the framework has already built much of the low level code and infrastructure for you.

I've used most of these at various points.

We have a number of simple Python applications that are just CGIs and static HTML files, such as our self-serve network registration system. While CGIs don't perform as well as the other alternatives, this is perfectly fine for lightly used services and the CGI performance disadvantages are somewhat overdramatized anyways; DWiki started out as entirely a CGI and did fine, and even today it spends much of its time running as a CGI. And DWiki is much bigger (and slower to start) than any sane CGI that you'll write.

However: if you're writing a CGI but not using things like Python's cgi module, you might as well write your app as a WSGI app even if you run it as a CGI with the standard's simple WSGI gateway. It's more future proof, less annoying, and you're not giving up anything.

For DWiki, I wound up writing a WSGI stack from the ground up. This was a great learning experience and probably made a lot more sense in 2006 than it does today. It's not worth it if you don't want a learning experience; use one of the existing, well regarded WSGI server sets and get on with what's actually important about your application.

Our new account request system is being written as a Django-based application because it involves a lot of non-trivial work with forms, things like dynamically displaying with preloaded values from data, multiple levels of validation, redisplay with error messages, and so on. I started out trying to write it as a CGI and soon came to the conclusion that this was a non-starter; using Django has made it feasibly simple.

(While I'm using Django's ORM and a sqlite database backend, this is just because Django makes it easiest to handle data this way, not because it's actually necessary for our problem.)

I think that DWiki is a good illustration of an application where you should choose WSGI over a framework. DWiki is too large to run as a CGI if it's under decent load, but it also does very little that a framework would be much help with; it has simple, minimal form handling and no interest in locking data up inside a database.

Written on 26 January 2011.
« The modern Python web application stack (as I understand it)
Not very much about Solaris NFS filehandles »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Jan 26 01:17:05 2011
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.