(One of the summaries of a talk at the 2014 djangocon.eu.)
Jacob Burch and Jacob Kaplan-Moss say Django is awesome. It comes with basically everything you need to get your site started. But it doesn’t come with everything. And sometimes you might want to rip something out and replace it with something else.
You could rip out the template engine and put jinja2 in. Or remove the views and only use REST and lots and lots of javascript. And you add redis or so to make communication between the frontend and backend. And slowly it isn’t so recognizable as a Django project anymore.
Django’s batteries-included nature is great, but sometimes those batteries hem us in. So they’re going to talk about ripping things out of django. You can see what goes well and in which places django fights back.
Something that is often replaced is django’s template language. You might want something more powerful or you might want a completely different template language.
Jinja2 is a common candidate. More expressive and it is often quicker. You do need to pass a regular python dictionary as context to jinja, though, instead of a django context. You can use https://github.com/jbalogh/jingo to make it easier for you.
They talked to mozilla, who are using jinja2 inside django, and they used it because they do quite some computation-intensive things in their templates. They got a lot of performance improvements out of it.
Often, however, the template layer totally isn’t the bottleneck, so swapping in jinja2 won’t be worth your time.
You cannot really get rid of views in Django. Views? That’s basically only a contract with the URL router: “a view is a callable which takes a request and returns a response”. “Request” means a django “HttpRequest” and response a subclass of django’s “HttpResponse”.
So… as long as you accept the request and return a response, you can already customize everything you want. There’s not a hard coupling with django’s models or django’s templates. You can grab any data you want from anywhere. Templates? You can just return json. No template in sight.
Callable? A function. A class is also fine, as long as it has a __call__()
method: that makes it a callable that you can call.
If you use django-rest-framework, you can grab your data from anywhere and return json. No template and model in sight. A common combination is django-rest-framework on the backend and angularjs on the frontend. Works really well. See for instance http://blog.kevinastone.com/getting-started-with-django-rest-framework-and-angularjs.html .
So: views are very very customizable.
django.contrib.auth. Well, this means a lot of buy-in. Authentication
middleware, session middleware, a modelbackend, a user model and also a
context processor. None of them do really very much, but they are used
together. And they’re all of them very secure.
Security is hard. Doing things insecurely is easy. So when you start replacing things, you need to Watch Out.
For a very fun bad example, look at https://github.com/jacobb/dj_minus_dj where public github gists are used for storing passwords :-) Bonus points for the hilarious roulette middleware that automatically logs you in as a random user… :-)
A typical use case to replace parts of the authentication layer is to use Single Sign On (SSO). (Note: I made a summary last friday with lots of SSO info: modern authentication in python web apps).
You could just use Redis and grab json out of there. But… frameworks are layered for a reason. Having a model layer is normal. Simply coupling your models directly in your view layer is an anti-pattern.
So if you want to replace django’s models, do continue to enforce strong separation of concerns. Recommended: use some existing encapsulation abstraction like sqlalchemy.
Also good: a POPO. A Plain Old Python Object. Just a class per model with some code to grab the object out of wherever you have your data and a method to kick it back in again.
But… after you replaced django’s models, the hurting starts.
Modelforms don’t work anymore.
The admin doesn’t work anymore.
Auth uses a django model. So that doesn’t work anymore.
You really really have to evaluate every external django app you use whether it still works.
It can be done, but it is a huge amount of work.
Templates are easy to replace.
Extending auth is fine, replacing out is pretty hard.
Views are OK to customize.
Models: it is easy to replace them, but it costs you a lot (admin, auth, etc).
What is left?
Settings. For the time being, we’ll just have to keep complaining about it, it’ll stay as-is. There are add-ons that can help you by grabbing config partially from the environment, for instance.
URL conf/routing.
Request - middleware - response is pretty much the core of django.
Forms. Why would you want to replace them?
Gare de Toulon
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):
