Manni Wood

I ported a database-backed web application from Java Servlets to Python/Django, and I’m so very happy that I did. I was nearing the end of work on a medium-sized web app when one of my programmers left for greener pastures. I decided that I could make up for the missing programmer by porting our J2EE app to Python, and then finish adding the final features to the Python port. The assumption was that Python would make me so much more productive that I’d finish faster even including the porting time.

It turns out I was right.

If you’ve taken to reading my blog at all, you’ll know that I love RDBMSs, and that my application designs use the RDBMs as the final arbiter of what the application’s data model is. So really, I wasn’t translating a huge amount of code for my port, because I could leave the database alone.

Of course, because I think the database is king, I opted out of using Django’s ORM on top of my carefully designed database. Instead, I ported iBATIS (which I was using in my J2EE version) to Pybatis, and used that for all of my database access needs.

I originally wanted to make Django’s templating system work with Pybatis (and maybe I still will some day), but I could not find an easy way to make Django’s templating system run well outside of Django, and I wanted Pybatis to be able to run in Python apps that were not neccesarily Django-based. So, I turned to the Jinja 2 templating engine, and liked it so much that I am now using it in both Pybatis and my Django app.

You may wonder what parts of Django this leaves behind, but, in my opinion, the parts of Django that I’m using are the parts that I had no desire to write. I love the way Django maps urls to functions, for instance.

I love the way Django renders templates to the browser. There’s no complicated forwarding from servlet to JSP as there is in Java-land; just a method call to the template engine, which you can hand whatever data structures you need for page rendering. It may sound like a small difference, but somehow, in practice, it’s a big difference. Like many things Java, Servlets and JSPs feel over-architected after using Django.

I also love using mod_wsgi and Apache with Django. It feels like a more natural fit than Apache with Tomcat. My production environment is Linux, so Apache is therefore process-based and not threaded. I prefer processes over threads as a general rule (I agree with Eric Raymond that threads are a performance hack; you can’t always avoid threads, but it’s nice when you can). So getting threaded Tomcat (or any other Servlet container) to talk to process-forked Apache always struck me as a bit of a mismatch.

With Django, there’s no mismatch: through mod_wsgi, each Apache process contains its own Python interpreter, and each Python interpreter contains a single copy of the web app. All kinds of good things come from this. For instance, my Python code does not have to be thread safe: each Apache process handles one request at a time, and each Apache process contains exactly one instance of the web app, so there’s no contention for resources. (Except on the database, but databases are designed to deal with that.)

With this setup, you don’t need connection pooling. Because Apache processes handle one request at a time, and because each process contains its own copy of the web app, each web app instance only needs to be configured with a single connection to the database. You just write your code to use The Connection, and the rest is taken care of for you by Apache’s pre-forking goodness. You just need to configure your database to handle as many open connections as your Apache setup will fork.

So not only does all this feel cleaner and simpler (though perhaps a tad more resource hungry—there are always tradeoffs), it’s also got horizontal scaling built in!

Well, mostly. There’s the problem of sessions. Apparently, Django can be configured to persist session data to shared memory, so that it doesn’t matter which Apache process responds to a user’s request, it has access to that user’s session. I decided to write my own session implementation that persists all session data in the database. (I don’t imagine this would work with large traffic volume, but for our product’s projected traffic volumes, this was fortunately an approach we could take.) That way, it wouldn’t matter if a user established a session on one Apache process and then returned to another Apache process on a different machine in our server farm: with sessions being stored in the database, they would be findable by any Apache process on any machine.

All in all, I’ve been very happy with the switch from J2EE to Django. Although there aren’t always Python equivalent to Java libraries I got used to using, I also found that porting to Python only the parts of Java libraries that I used took very little time.

The realities of the market are such that my next project may be a J2EE project: it’s still the most popular stack, so the opportunity to use Python is not always there. But if I’m in a position to choose, I’ll choose Python. If I’m in a position to offer a recommendation, I’ll recommend Python if I think the library support is there, and the project can benefit from that choice.