ere’s a lot of hype around swapping out core parts of Django’s stack for other pieces. Should you do it?
Short Answer: Don’t do it. ese days, even Instagram says on Forbes.com that it’s completely unnecessary:http://2scoops.co/instagram-insights
Long Answer: It’s certainly possible, since Django modules are simply just Python modules. Is it worth it? Well, it’s worth it only if:
ä You are okay with sacri cing your ability to use third-party Django packages.
ä You have no problem giving up the powerful Django admin.
ä You have already made a determined effort to build your project with core Django com-ponents, but you are running into walls that are major blockers.
ä You have already analyzed your own code to nd and x the root causes of your problems.
For example, you’ve done all the work you can to reduce the numbers of queries made in your templates.
ä You’ve explored all other options including caching, denormalization, etc.
ä Your project is a real, live production site with tons of users. In other words, you’re certain that you’re not just optimizing prematurely.
ä You’re willing to accept the fact that upgrading Django will be extremely painful or im-possible going forward.
at doesn’t sound so great anymore, does it?
Chapter 14: Tradeoffs of Replacing Core Components
14.1 The Temptation to Build FrankenDjango
Every year, a new fad leads waves of developers to replace some particular core Django component.
Here’s a summary of some of the fads we’ve seen come and go.
Fad Reasons
Replacing the database/ORM with a NoSQL database and corresponding ORM replacement.
Not okay: ``I have an idea for a social network for ice cream haters. I just started building it last month. I need it to be web-scale!!!1!''
Okay: ``Our site has 50M users and I'm hitting the limits of what I can do with indexes, query optimization, caching, etc. We're also pushing the limits of our Postgres cluster. I've done a lot of research on this and am going to try storing a simple denormalized view of our activity feed data in Redis to see if it helps.''
Replacing Django's template engine with Jinja2, Mako, or something else.
Not okay: ``I read on Hacker News that Jinja2 is faster. I don't know anything about caching or optimization, but I need Jinja2!''
Not okay: ``I hate having logic in Python modules. I just want logic in my templates!''
Sometimes okay: ``I have a small number of views which generate 1MB+
HTML pages designed for Google to index!''
Table 14.1: Fad-based Reasons to Replace Components of Django
14.2 Case Study: Replacing the Django Template Engine
Let’s take a closer look at one of the most common examples of replacing core Django components:
replacing the Django template engine withJinja2.
14.2.1 Excuses, Excuses
e excuse for doing this used to be performance. at excuse is no longer quite as valid. A lot of work has gone into improving the performance of Django’s templating system, and newer benchmarks
14.2: Case Study: Replacing the Django Template Engine indicate that performance is greatly improved.
A common excuse for replacing the Django template engine is to give you more exibility. is is a poor excuse because your template layer should be as thin as possible. Case in point, adding ‘ exibility’
to templates also means adding complexity.
14.2.2 What if I'm Hitting the Limits of Templates?
Are you really? You might just be putting your logic in the wrong places:
ä If you are putting tons of logic into templates, template tags, and lters, consider moving that logic into model methods or helper utilities.
ä Whatever can’t be placed into model methods might go into views.
ä Template tags and lters should be a last resort. We covered this in more detail inchapter 13
‘Template Tags and Filters’.
14.2.3 What About My Unusual Use Case?
Okay, but what if I need to generate a 1 MB+ HTML page for Google to index?
Interestingly enough, this is the only use case we know of for replacing Django 1.5 templates. e size of these pages can and will crash browsers, so it’s really meant for machines to read from each other. ese giant pages require tens of thousands of loops to render the nal HTML, and this is a place where Jinja2 (or other template engines) might provide a noticeable performance bene t.
However, besides these exceptions, we’ve found we don’t need Jinja2. So rather than replace Django templates across the site, we use Jinja2 in only the affected view:
. .
E .
# flavors/views.py import os
from django.conf import settings from django.http import HttpResponse
from jinja2 import Environment, FileSystemLoader
Chapter 14: Tradeoffs of Replacing Core Components
. . from syrup.models import Syrup
JINJA2_TEMPLATES_DIR = os.path.join(
settings.PROJECT_ROOT,
"templates",
"jinja2"
)
JINJA2_LOADER = FileSystemLoader(JINJA2_TEMPLATES_DIR) JINJA2_ENV = Environment(loader=JINJA2_LOADER)
TEMPLATE = JINJA2_ENV.get_template("big_syrup_list.html")
def big_syrup_list(request):
object_list = Syrup.objects.filter()
content = TEMPLATE.render(object_list=object_list) return HttpResponse(content)
As we demonstrate, it’s pretty easy to bring in the additional performance of Jinja2 without removing Django templates from a project.
14.3 Summary
Always use the right tool for the right job. We prefer to go with stock Django components, just like we prefer using a scoop when serving ice cream. However, there are times when other tools make sense.
Just don’t follow the fad of using a fork for ice cream!