I’m taking up the gauntlet. A gauntlet that has been thrown down with considerable force and eloquence by my colleague Gijs on his new weblog in a post called Django is just an API. The title comes from a similar article about Rails being just an API.
Summary: we use all of Django (models, templates, views, staticfiles, etc). Reusable apps. Two big core apps that everything inherits from for basic user interface and basic map handling.
To quote Gijs: … we are currently transitioning to API-based de-coupling of back-end and front-end. In other words: a client-side user interface which talks to an API for data. This web app should just be one of the api-consuming clients, not privileged in any way compared to an iPhone or Android native client.
So: Django is relegated to the dustbin of history and is mercifully allowed to serve up an API (probably until it is replaced in due course with some node.js goodness). Yes, I’m being over-the-top melodramatic here :-)
Not too quick, though: the “we are currently transitioning” quote should be qualified as being limited, at the moment, to one single full-blown all-out experiment on a big project. All our other projects still use ye olde Lizard with the whole Django stack.
“We are transitioning” is right in that there seems to be management buy-in.
That dustbin-of-history stack of Django apps called Lizard? The basis was made by me and another colleague. Apps as nicely releaseable python packages? With repeatable buildouts? Internal python package server? Current user interface? Documentation? Test setup? There’s a really big piece of me and my thinkwork and my preferences in there.
Gijs calls this a paradigm shift. When someone has worked on traditional websites using Django, Rails, PHP, Plone or you name it, the paradigm shift to API based application design is incredibly hard to wrap your head around.
Is it a problem for me? Am I resisting change? I got some flak at a previous job for sticking too long to a particular tool (“archgenxml” for those who know it) when I should really have moved along. Since then I’m a bit anxious to not be too conservative.
According to Gijs, programmers can develop the technological conservatism syndrome as they get older. Age-wise I’m number 4 in a company of 50 at the ripe age of 40 :-) Is it potentially a career-ending syndrome? In any case I “should be ready to learn new things” or there’s a nice place for me right next to the dustbin where Django already is in.
But there are sites/apps/pages that are best done in a different way. And some sites just need more server-side power and control. Here are some of the theoretical and practical notes I’d like to give to you for consideration:
(Ok, most of our lizard sites couldn’t care less if they’re indexed or not. At least we’re not actively aiming and designing for that. The nature of the data doesn’t require it. But it would be fun to try and make google results meaningful for our sites.)
According to Gijs, … this web app should just be one of the api-consuming clients, not privileged in any way compared to an iPhone or Android native client.
The only economically sane way forward for us as a company is to have a good responsive multi-device layout. But then there’s no theoretical need to shift lots of code to the client side (at least not because of the equal-footing-for-iphone reasons).
Some extra points I’d like to raise:
The goal of Lizard is to make lots of different kinds of data sources available and combinable in one system. One of the two cores of the current Lizard is an “adapter mechanism” that ties the generic map/search/click/graph handling to arbitrary data sources. The other core is a generic user interface that you can customize and tweak, for instance by subclassing. All those various data sources all need different tweaks and customizations. Lizard allows that.
Repeatability, rebuildability, customizability.
I started reading the new Django book two scoops of Django last week. Wow, that provided me with some welcome support: Django is pretty good and useful. Really.
Oh, and I’d love to make our Python-internal adapter mechanism a bit more explicit and turn it partially into an API. Lizard is a bigger project than just our company. There are quite a lot of partners! (See http://lizard.net/ if you speak Dutch). An API would make it easier to connect their custom data sources with the rest of Lizard (compared to needing a bunch of Python code). Up to a certain level this could work real well. And if more functionality is needed, we can do the real Python integration anyway.
Another wishlist item: a more responsive layout. The previous version worked OK on the desktop. The current version also works on an iPad. The next version should also work comfortably on an iPhone.
All those wishes? There’s nothing in Django holding them back. And there’s a lot of Django you can use to make it possible.
I’ve now made myself completely impossible. And I’ve made a fool out of myself. Publicly. I’ll just slink away quietly now to the house of demented elderly programmers.
That is, unless somebody shoots me first for being too verbose and for loving flowery language too much and for making my sentences (and this whole article) too long :-)
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):