Kenneth will try to go easy on Django, he actually likes it. So it won’t be the customary “django sucks” talk :-)
He’s made http://python-guide.org, the hitchhiker’s guide to python. Documented best practices, a reference for seasoned veterans, a guidebook for newcomers.
His most popular library is requests, http for humans. Way easier than the build-in stuff in python itself.
How he wants to approach this talk: open source all the things. It is a helpful mindset to at least treat everything you make like it will be open sourced, even if you won’t actually do it. This gives you several benefits:
Let’s build something with django! It has benefits. You have piece of mind because of security decisions that django makes. You won’t feel lost as it has excellent docs. It provides lots of things: a ORM, user/authentication, template system, etc.
Django is a monolithic application. You have all the benefits of the full django stack everywhere. Everything is packaged handily together. Everything is one place. Easy deployment.
But the single django codebase also means that the components are tightly coupled. Admin and models; auth all over the place, everything is connected. You need a lot of (tribal) knowledge. Iteratively changing components is difficult, so technical debt has a tendency to spread all over the place. You also need to deploy everything at once.
A good thing is to look at constraints. Constraints foster creativity. Text editor versus IDEs, for instance. The constraint of a text editor might help you.
Constraint: you might design your app as a service. This is a great way to structure your app:
You can have API talk to an API which again talks to API. Independent. Some use a message queue, some use persistence. What if you use Django for an app you’ve set up in this way as a service? An API service and a frontend client?
If we use django for serving the API:
if request.method == POSTis jucky.
What’s actually left of django that we actually use in this server?
And what if we use a separate django site as an API consumer? Database is handled by the API server, so we don’t really need one. But for user management lots of other things we do need a database anyway. Again, what is actually left of django that we actually use here?
Now, let’s look at Flask. It is, like django, a WSGI application. It uses Jinja2 as a template language (which looks like django’s). It also has an active community and lots of extensions.
It started as an april’s fool joke. Really.
Note by Reinout: what struck me at the time of that joke was the importance of PR. There was some irritation that a joke (with proper PR) would get much more attention than real work with real effort behind it (but without proper PR). See the april 1 postmortem, especially the “what I learned” section.
800 lines of code
1500 lines of tests.
Exhaustively documented: 200 pages of code.
Layered API, build on werkzeug and wsgi.
Some differences with django:
Why is it better?
return (content, status)and it’ll convert it into a response object automatically.
There are many extensions. Some popular ones: flask-sqlalchemy (database mapper), flask-celery (delayed jobs), flask-script (management commands), flask-wtf (form validation).
Tip: use http a lot, that way you’re implementation-agnostic.
Note: his slides are online.
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):