How powerful is Django

Raphael Michel

Patrick asked me to write down things about Django that go beyond the basic workshop I gave recently. I'm not quite sure what to write about it and how much of it is actually interesting, but I just sifted through the code of my completed and ongoing Django projects and wrote down what I thought might be useful to other developers be. I divided the whole thing very loosely into different sections, but otherwise didn't sort it any further.

As a general rule

Use Python 3. Please. And Django 1.7+. Thanks. And read more in the documentary, it is almost completely worth reading. :-)

Project structure

Django offers the option of converting the project into so-called Apps to split up. The idea behind it is mainly that of the reusability of apps, which I consider unrealistic in reality so far, but it can still make sense to use this option. So far I have tried different approaches in different projects, starting with a monolithic model with a gigantic app, as well as additional, "small" apps for meta-functions such as analysis and statistics, up to a division into several interchangeable apps (e.g. one for the backend and one for frontend), which must not depend on each other, and an app with common functions and models, on which all others depend. Different apps for different features are often useful, but mostly not realistic for me because the features are too closely related and integrated into each other.

Which approach makes sense depends very much on the project, but so far I have been best with the latter structure.

By default, Django creates one, one, one and one per app. While with and you can get by with one file for a long time, with and it is useful to know that Django doesn't mind if you make a subpackage out of it and split it up into several files.


For debugging, I recommend the well-known Django Debug Toolbar, which is not only very useful for debugging itself, but also for keeping an eye on the ORM: Unfortunately, if you write code carelessly, it is easy to get extreme produced many database queries. The problem usually falls in the development phase, when you are working with small test data sets, but it often does not occur but causes a huge load as soon as you go into production. Rule of thumb: Every action should cause a constant (or constant upwardly limited) number of database queries, which should be independent of the number of data records.

In production, when users complain, django-impersonate is a useful tool to understand errors.

Static files

For any larger project, you will probably want to write LESS or SASS rather than CSS code. The django-compressor handles this for you in the same way as it can compress CSS and JavaScript. In development mode it does this live and transparently, in production it can be precompiled.


Take a look at the documentation and keep in mind that the default setting is set to: If you delete a referenced object, all referencing objects are also deleted. That can cost you your head (tested for you) and in almost all cases you are with or better advised.


For some time now, Django has made it easy to create your own User-Models to use instead of the supplied one. Make use of this option early - if the need arises later, a migration in productive operation is possible, but quite time-consuming1.


Django's signal framework is much more powerful than it looks at first glance. There will probably be a lecture or an extra blog post from me about this at some point.

Background processes

There is almost no case in which it is justified to keep the user waiting for an answer. You should therefore avoid doing anything in a view that could take a long time. I use Celery as a task queue for everything that can take longer or depends on external availability, be it the export of a lot of data or the simple sending of emails.

For cronjob-like things, I used to use django-cron, but have to look for an alternative or port it to Python 3.


It is worth considering replacing Django's template engine with Jinja2. I did this in a project because I had to map things that would have been very cumbersome in Django's TE and will probably do it more often when Django 1.8 is released, which will offer significantly better support for external template engines.


At the beginning of my work with Django, I neglected the power of class-based views and used them far too little. I can only recommend you to take a close look at them.

Unit tests

If you want to do real interface tests, Django can be connected to Selenium quite well with the help of the2.


Even if I haven't had the dubious pleasure of bringing a multilingual project into production, I can give the tip that, if you ever want to do it, you can't plan it early enough.