Flasky goodness (or why django sucks?) - Kenneth Reitz¶

Tags: django, djangocon

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:

• Components become concise and decoupled.

• Concerns separate themselves.

• Docs and tests become crucial.

• Best practices emerge, like not putting passwords in the code.

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:

• Components become concise and decoupled.

• Concerns separate themselves.

• Best practices emerge, so you can use the ideal tools.

• Documentation becomes critical.

• The various components can scale separately.

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:

• Significant amount of boilerplate code for relatively simple views.

• No need for templates and template tags, that’s all in the frontend. We’re just the API.

• API libraries are a bit buggy, they could use some love.

• if request.method == POST is 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:

• You have an explicit application object that you can also pass to your tests.

• Simple elegant API without boiler plate.

• You need to bring your own batteries. No built-in ORM or form validation or so.

Why is it better?

• Jinja2 is better and faster than django’s.

• There are fewer built-in batteries, so you’re more flexible. (Jinja2 isn’t bundled, it is just a dependency.)

• The configuration is just a simple dictionary, not the magic stuff that django does.

• If you want to build a monolithic application, it is actually quite hard.

• You get the great werkzeug debugger.

• There are no import-time side effects.

• Signals are great; in flask they’re luckily outside of the ORM.

• Your tests are simpler as you have real application objects.

• You can do 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.