Reflections on Django
Django made its way into my life in 2012 as the answer to what was frankly a pitiful, PHP-driven, personal website. Accustomed to writing one-off SQL statements and frequent FTP transfers to keep the site running, Django was a breath of fresh air. After setting up an Amazon Web Services EC2 instance and a GitHub repository, I was ready to bite the bullet and bring my web development skills into the 2010s.
To this day I consider the move a mild success. I’m able to make changes quickly and flexibly, often leveraging Django features to get things done. Careful thought has gone into this framework, which is reflected in its 1K+ contributors and adoption by industry leaders such as Instagram and Robinhood. What started as a management system for news and media companies has expanded well beyond that scope into a key tool for web developers in a variety of fields.
After three years getting acquainted with Django I found an opportunity to pursue it full time. At the time, JSTOR had a migration project well underway to move off of a third-party platform and onto one powered in part by Django. Having worked on a handful of small projects I was hopeful that my experience was ready to scale up to a project of JSTOR’s size.
A few years later, we’ve successfully freed ourselves from the old platform. We’ve learned so much along the way that I’ve probably forgotten more than I remember. As with any large project with deadlines, we’ve also accumulated some technical debt. A significant part of this debt, in my mind, is how we’re using Django.
A decision was made early on that our data would be provided through microservices independent of the Django framework. This meant that we would benefit from things like fault tolerance and isolation with the tradeoff that we couldn’t leverage features of the framework to get our data. While Django is highly customizable, its ORM is rather rigid. We have many reasons to stick with our approach, but the thing I miss most is the expressivity of the ORM. We’re spending some time identifying opportunities to benefit from it in our newer applications.
At the code organization level, Django is typically structured as a project with many apps. At JSTOR we started with a single project and a single app, which eventually grew too large. Rather than splitting functionality into other apps within the project, we went down the road of creating separate projects for each piece of functionality. This benefited, again, from fault isolation and tolerance but has cost us quite a bit in terms of reusability.
A Django project’s settings.py file defines all the necessary configuration for the project including which middleware runs and what databases to speak to. Typically, all applications within a project can reuse these settings. When using multiple projects, each needs to replicate the settings file in its entirety, customizing bits and pieces for its own devices. This introduces room for human error when we have a change that requires updating all the settings files, as well as confusion later when something doesn’t work as expected.
An incredibly useful feature of Django is its URL resolving capabilities. Given an “auth” app and a “profile” app, one could typically write something like:
from django.http import HttpResponseRedirectdef profile(request):
if not request.user.is_authenticated():
return HttpResponseRedirect(reverse('auth:login'))
If the user isn’t authenticated, they get redirected to whatever URL is defined in the “auth” namespace named “login.” When dealing with multiple projects, reverse breaks. A given project knows nothing about the URLs defined in another project. This necessitates hard-coding of URLs or finding a kludgy way to manage them in a shared way.
Traction is picking up on exploring what a world with a single Django project might look like. The benefits are rather clear but care needs to be taken to maintain the resiliency and isolation we currently enjoy. There are great ideas to explore, and we’ve finally got the time to explore them! It’s a bright future.
Have you experienced a migration to Django? Have you solved any of the issues above? We would love to hear from you below, and we’d also like to talk to you about our open positions.
