Djangocon: Avoiding monoliths - Hanna Kollo¶

Tags: django, djangocon

(One of the summaries of a talk at the 2015 Djangocon EU conference).

Hanna Kollo talks about one of the biggest anti-patterns in software development: monoliths. She works at spilgames, where they use lots of django and python. The load sensitive components are written in Erlang, but the internal tools are mostly python/django.

She works mostly on the internal tools. It are business-driven applications, so they have changing requirements and it is a huge challenge to keep the code clean. If you don’t watch out, you end up with one monolithic piece of code.

A monolithic django app is one app. No modularity. One models.py, once set of views. Spaghetti code: everything is connected to everything. (Note: often a monolithic application is described as not having multiple layers. She looks at it more from a django viewpoint.)

Monoliths are hard to understand. It is hard to make changes. Hard to reuse. Hard to decide what impacts what.

The example she gave was about an internal publishing project. Basically a CMS for games. They designed a strong architecture: a modular structure. Enforced. Many small aps. She showed the dependency graph: it was one big hierarchy of apps. This wasn’t a monolith, but it had many of the same problems. Everything referenced everything.

On a second try, they started with one app to get to a stable point quickly (“minimum viable product”). And once it made sense, they splitted something out into a separate app. They ended up with bigger apps than in the first try. The smaller number of apps meant that there were fewer connections. And connections from one app to another is what makes it harder to reason about and to understand.

The result from the second try was much better. No monolith, no spaghetti code. Growth is possible. But… the business requirements keep coming. There is a risk of the apps growing too big.

The solution they found was to do something that’s not normally done in Django projects. Django advises you to have big models and thin views. What they did was to add a layer on top of the models. They call it a “services” layer. They did it because their business logic is not just models. There is much behaviour in their business logic. So you normally use the services layer in your views without going directly to the models.

Anyway, keeping the number of apps down is a good idea.