Flasky Goodness (or Why Django Sucks?)¶
by Kenneth Reitz
- http://twitter.com/kennethreitz
- Works for Heroku
Hos Open Source work¶
-
- Documented best practices
- Guidebook for newcomers
- Reference for seasoned veterans
- Don’t panic & always carry a towel
-
- HTTP for humans
legit: Git workflow for Humans
Envoy: Subprocess for Humans
Tablib: Tabular Data for Humans
Clint: CLI App Toolkit
Autoenv: Magic Shell Environments
OSX-GCC Installer: Provokes Lawyers
Open Source All The Things!¶
- Components become concise and decoupled
- Concerns separate themselves
- Best practices emerge
- Documentation and tests become crucial
- Code can be released at any time
- Abstraction
Let’s build something¶
Why pick Django?
- Makes modular decisions for you
- Makes security decisions for you
- Excellent documentation
- Installable third-party Django apps
- Tremendous resources & Community
- much more cause anything is possible!
Django Application¶
Tools & Utilities
- Management Tools
- Supporting Services
Web Process
- User Interface
- API
- Data Persistence
- CRUD Admin
- Authentication
Worker Process
- Deferred Tasks
- Scheduled Tasks
Single Codebases are great¶
- All the benefits of the Django stack
- Figure out architecture as you go
- Shared modules keep you dry
- Make broad, sweeping changes
- Only need to deploy once
Single codebases are EVIL!¶
- Tight coupling of components
- Broad tribal knowledge required
- Iterative change of components difficult
- Technical debt has a tendency to spread
- Forced to deploy everything at once.
Anything is possible… but that ends up with a monolithic application.
CONSTRAINTS FOSTER CREATIVITY¶
- Having rules gives you an environment in which to play.
- Text Editors vs IDEs (Vim lets you do so much, Sublime Text limits what you can do)
- Prime vs Zoom Lenses
- Mac OS X vs Desktop Linux
- Pen/paper vs electronic notes
Build for services¶
Components become concise & decoupled
Concerns separate themselves
Best practices emerge
Documentation and contracts become crucial
Note
missed some here
Results in composability
Django: For API Services¶
- Significant boilerplate code for simple views
- No need to templates, tags, etc
- API Libraries are buggy; could use some love
- if
request.method == 'POST'
Django: For API Consumer¶
- Keep in mind, database is handled by the API
- Makes modular decisions for you
- Deals with the database for you
- Installable third-party Django apps
Enter Flask¶
- HTTP Web Framework based on Werkzeug
- Excellent for building web services
- Elegant and simple
Flask Familiarities¶
- WSGI Application Framework
- Jinja2
- activity community
- Started an April Fool’s joke
- Just 800 lines of code
- Heavily tested, 1500 lines of tests
- Exhaustively document; 200 pages of docs
- Layered API; built on Werkzeug, WSGI
Flask Differences¶
- Explicit & Passable app objects
- Simple, elegant API. No boiler player
- BYOB: Bring your own batteries
- No built-in ORM or form validation
- Context locals. Keeps things looking clean
Flask Improvements¶
- Fewer batteries == greater flexibility
- Jinja2 is an incredible template system
- Everything harnesses actual references
- Configuration is a simple dictionary
- It’s hard to build monolithic applications
- Response objects are WSGI applications
- Werzueg debugger
- No import-time side effects
- Signals system outside of ORM
- Tests are simpler with real app objects
return (content, status)
Popular Flask Extensions¶
- Flask-SQLAlchemy: Database Mapper
- Flask-Celery: Delayed jobs
- Flask-Script: Management commands
- Flask-WTF: Form Validation
Services are agnostic¶
- Just speak HTTP
- Use both Django and Flask