Django RAPID architecture¶
By Jamie Matthews, co-founder at DabApps.
Django RAPID Architecture1 describes and advocates for a coherent collection of patterns and idioms for successful, maintainable and robust Django codebases, distilled from 15+ years of experience and over 100 production projects.
A word from our sponsor
DabApps is a UK-based web and mobile agency. We design and build bespoke software for ambitious clients. We love Django and use it for all server-side code. We offer consultancy services for Django and Django REST framework. Get in touch!
Django is a big box of practical tools that make the task of developing software for the Web efficient and enjoyable. But any set of tools, even tools that are designed beautifully to work together, can't by themselves tell you how to actually use them to build something that will stand the test of time.
Suggestions can be found, at varying levels of implicitness or explicitness, in the Django documentation. In addition, the community has coalesced around loosely-defined best practices that, like folk tales, are passed down from developer to developer, spread from company to company, argued about in the bar at conferences, and described in the crumbling blogs of a thousand burned-out developers.
Over the years, attempts have been made to collect and curate these best practices. Many of the patterns described here are inspired by and adapted from those styleguides, and in some ways, this book is just another one of those collections. But it does differ in a couple of ways.
Firstly and foremostly, it tries to be simple.
Quote
A complex system that works is invariably found to have evolved from a simple system that worked.
Systems that are successful are those that are built on simple foundations. Of course, software systems often end up extremely complex, but if they don't start simple, they're bound to fail.
Crucially, the path from simple to complex must be smooth and predictable. Many patterns, libraries and best practices in software contain complexity cliffs: sudden, hidden discontinuities between the effort required to build something simple, and the effort required to build something seemingly only slightly less simple. The approaches recommended here attempt to avoid this wherever possible.
Note that simple is not the same as easy. Some of the concepts in this guide can be quite difficult to understand at first. Please watch this brilliant keynote from Rich Hickey to understand the difference.
Secondly, it tries to be flexible.
This guide is prescriptive about the things that really matter, and less prescriptive about the things that don't. The opinions and experiences of individual developers are vital, and a disagreement with one or two aspects of this guide should not result in a rejection of the entire philosophy. It's intended to be modular: you are encouraged to pick and choose the ideas that you like, and reject the ones that you don't. Do you enjoy using type hints in Python? Use them. Don't like them? Don't bother. The most important part of this guide is the structure of the shed, not the colour it's painted.
Quote
When you decide to go the "service" route, you are changing the nature of your business. This is related to an argument I bring up occasionally when people tell me they don’t use "frameworks" and never will: what they actually mean, whether they realize it or not, is "we built and now have to maintain and train our developers on our own ad-hoc private framework, on top of whatever our normal business is".
Django is extremely good, and any tooling that attempts to hide or replace parts of it is unlikely to be successful in improving on it. Django knowledge is also attractive on the job market, so learning RAPID should only help push Django knowledge forward, not hinder it.
Some of the ideas presented here do restructure or reinterpret the way some of Django's internal APIs work, but they do not hide or replace them. The concepts and constituent parts are all there, they're just in different places. This sounds somewhat cryptic, but hopefully will make sense as you read through the guide.
The guidelines proposed here do not constitute a "service layer".2
Anti-goals¶
This guide is not intended to teach you Django. It may help with your learning journey, but it assumes a decent level of familiarity with Django itself.
How should I read this?¶
It's best to treat this documentation as a book. While it can be used as a reference to dip in and out of, some of the concepts might seem a bit surprising without the context of the discussions in earlier chapters.
Inspiration¶
Many of the ideas presented here are not new. The links below have all, to a greater or lesser extent, planted some of the seeds for this guide, and thanks and credit is due to all of them.
- How to Structure Django Projects by James Beith.
- HackSoft Django Styleguide.
- Choose Boring Technology by Dan McKinley.
- The Grug Brained Developer.
-
A note on naming. The name was originally "Django RAID Architecture", an acronym for Readers, Actions, Interfaces, Data. But I decided RAPID sounds better, so added the P. If it helps, maybe the P stands for Patterns. ↩
-
Unless it's beneficial to the adoption of this approach that Management consider it to be a service layer; in which case, it's most certainly a service layer. ↩