The document discusses implementing a multi-tier architecture in Django. It describes using a single Django proxy server that can select templates, database connections, and URL resolvers at runtime based on the request. Key points covered include using middleware, thread locals, template loaders, database routers, and the django.db.connections module to enable runtime selection of these components. The document also stresses that the entire rendering pipeline must be configurable on a per-request basis and cautions that caching without a cache manager can cause issues.

1. Multi-tier Implementation
in
Django
Sebastien Mirolo
@seabasscapoeira
smirolo@djaodjin.com

2. djaodjin-saas
Software-as-a-Service as a Django App

3. Productized: HTTP Firewall
One Django Proxy Server,
with runtime selection of:
- templates
- database connections
- urlresolvers

4. Disclaimer
“In theory there is no difference between
theory and practice. In practice there is.”
- Yogi Berra
PLEASE, DO TRY THIS AT HOME !

5. Runtime Selection
Templates
• middleware
• thread local
• template loaders

6. Runtime Selection
Databases
• middleware
• thread local
• database routers
• django.db.connections.databases

7. Runtime Selection
reverse(url_name)

8. LESSONS LEARNED
 Caching without a CacheManager is Evil.
def value(self):
if not has_attr(self, _value):
self._value = self.compute_value()
return self._value
 The Entire Rendering Pipeline must be Configurable on a Request.
 (not talked here) Class Views and Mixins are amazingly flexible.

9. Thank You
Sebastien Mirolo
@seabasscapoeira
smirolo@djaodjin.com

10. Thank You
Sebastien Mirolo
@seabasscapoeira
smirolo@djaodjin.com