django in the real world

Download Django in the Real World

Post on 08-Sep-2014




1 download

Embed Size (px)


There's plenty of material (documentation, blogs, books) out there that'll helpyou write a site using Django... but then what? You've still got to test,deploy, monitor, and tune the site; failure at deployment time means all yourbeautiful code is for naught.


  • django Django in the Real World James Bennett Jacob Kaplan-Moss PyCon 2009 1
  • So youve written a web app... 2
  • Now what? 3
  • API Metering Distributed Log storage, analysis Backups & Snapshots Graphing Counters HTTP Caching Cloud/Cluster Management Tools Input/Output Filtering Instrumentation/Monitoring Memory Caching Failover Non-relational Key Stores Node addition/removal and hashing Rate Limiting Autoscaling for cloud resources Relational Storage CSRF/XSS Protection Queues Data Retention/Archival Rate Limiting Deployment Tools Real-time messaging (XMPP) Multiple Devs, Staging, Prod Search Data model upgrades Ranging Rolling deployments Geo Multiple versions (selective beta) Sharding Bucket Testing Smart Caching Rollbacks Dirty-table management CDN Management Distributed File Storage 4
  • Whats on the plate Structuring for deployment Testing Production environments Deployment The rest of the web stack Monitoring Performance & tuning 5
  • Writing applications you can deploy, and deploy, and deploy... 6
  • The extended extended remix! 7
  • The fivefold path Do one thing, and do it well. Dont be afraid of multiple apps. Write for flexibility. Build to distribute. Extend carefully. 8
  • 1 9
  • Do one thing, and do it well. 10
  • Application == encapsulation 11
  • Keep a tight focus Ask yourself: What does this application do? Answer should be one or two short sentences 12
  • Good focus Handle storage of users and authentication of their identities. Allow content to be tagged, style, with querying by tags. Handle entries in a weblog. 13
  • Bad focus Handle entries in a weblog, and users who post them, and their authentication, and tagging and categorization, and some flat pages for static content, and... The coding equivalent of a run-on sentence 14
  • Warning signs A lot of very good Django applications are very small: just a few files If your app is getting big enough to need lots of things split up into lots of modules, it may be time to step back and re- evaluate 15
  • Warning signs Even a lot of simple Django sites commonly have a dozen or more applications in INSTALLED_APPS If youve got a complex/feature-packed site and a short application list, it may be time to think hard about how tightly- focused those apps are 16
  • Approach features skeptically 17
  • Should I add this feature? What does the application do? Does this feature have anything to do with that? No? Guess I shouldnt add it, then. 18
  • 2 19
  • Dont be afraid of multiple apps 20
  • The monolith mindset The application is the whole site Re-use is often an afterthought Tend to develop plugins that hook into the main application Or make heavy use of middleware-like concepts 21
  • The Django mindset Application == some bit of functionality Site == several applications Tend to spin off new applications liberally 22
  • Django encourages this Instead of one application, a list: INSTALLED_APPS Applications live on the Python path, not inside any specific apps or plugins directory Abstractions like the Site model make you think about this as you develop 23
  • Should this be its own application? Is it completely unrelated to the apps focus? Is it orthogonal to whatever else Im doing? Will I need similar functionality on other sites? Yes? Then I should break it out into a separate application. 24
  • Unrelated features Feature creep is tempting: but wouldnt it be cool if... But its the road to Hell See also: Part 1 of this talk 25
  • Ive learned this the hard way 26
  • One application Includes bookmarking features Includes tagging features Includes rating features 27
  • Should be about four applications 28
  • Orthogonality Means you can change one thing without affecting others Almost always indicates the need for a separate application Example: changing user profile workflow doesnt affect user signup workflow. Make them two different applications. 29
  • Reuse Lots of cool features actually arent specific to one site See: bookmarking, tagging, rating... Why bring all this crap about code snippets along just to get the extra stuff? 30
  • Advantages Dont keep rewriting features Drop things into other sites easily 31
  • Need a contact form? 32
  • urlpatterns += (, (r^contact/, include(contact_form.urls)), ) 33
  • And youre done 34
  • But what about... 35
  • Site-specific needs Site A wants a contact form that just collects a message. Site Bs marketing department wants a bunch of info. Site C wants to use Akismet to filter automated spam. 36
  • 3 37
  • Write for flexibility 38
  • Common sense Sane defaults Easy overrides Dont set anything in stone 39
  • Form processing Supply a form class But let people specify their own if they want 40
  • Templates Specify a default template But let people specify their own if they want