sr.ht is a large, production-scale suite of web applications (I call them “mini-services”, as they strike a balance between microservices and monolithic applications) which are built in Python with Flask. David Lord, one of the maintainers of Flask, reached out to me when he heard about sr.ht and saw that it was built with Flask. At his urging, I’d like to share the rationale behind the decision and how it’s turned out in the long run.
I have a long history of writing web applications with Flask, so much so that I think I’ve lost count of them by now - at least 15, if not 20. Flask’s simplicity and flexibility is what keeps bringing me back. Frameworks like Django or Rails are much different: they are the kitchen sink, and then some. I generally don’t need the whole kitchen sink, and if I were given it, I would want to change some details. Flask is nice because it gives you the basics and lets you build what you need on top of it, and you’re never working around a cookie-cutter system which doesn’t cut your cookies in quite the way you need.
In sr.ht’s case in particular, though, I have chosen to extend Flask with a new module common to all sr.ht projects. After all, each service of sr.ht has a lot in common with the rest. Some of the things that live in this core module are:
- Shared jinja2 templates and stylesheets
- Shared rigging for SQLAlchemy (ORM)
- Shared rigging for Alembic
- A little validation module I’m very proud of
- API behavior, webhooks, OAuth, etc, which are consistent throughout sr.ht
The mini-service-oriented architecture allows sr.ht services to be deployed ala-carte for users who only need a fraction of what we offer. This design requires a lot of custom code to integrate all of the services with each other - for example, all of the services use a single shared config file, which contains both shared config options and service-specific configuration. sr.ht also uses a novel approach to authentication, in which both user logins and API authentication is delegated to an external service, meta.sr.ht, requiring further custom code still. core.sr.ht additionally provides common SQLAlchemy mixins for things like user tables, which have many common properties, but for each service may have service-specific columns as well.
Django provides their own ORM, their own authentication, their own models, and more. In order to meet the design constraints of sr.ht, I’d have spent twice as long ripping out the rest of Django’s bits and fixing anything that broke in the resulting mess. With Flask, these bits were never written for me in the first place, which gives me the freedom to implement this design greenfield. Flask is small and what code it does bring to the table is highly pluggable.
Though it’s well suited to many of my needs, I don’t think Flask is perfect. A few things I dislike about it:
- First-class jinja2 support is probably out of scope.
- flask.Flask and flask.Blueprint should be the same thing.
- I’m not a fan of Flask’s approach to configuration. I have a better(?) config module that I drag around to all of my projects.
And to summarize the good:
- It provides a nice no-nonsense interface for requests, responses, and routing.
- It has a lot of nice hooks for adding your own middleware.
- It doesn’t do much more than that, which means you’re free to choose and compose other tools to make up the difference.
I think that on the whole it’s quite good. There are frameworks which are smaller still - but I think Flask hits a sweet spot. If you’re making a monolithic web app and can live within the on-rails Django experience, you might want to use it. But if you are making smaller apps or need to rig things up in a unique way - something I find myself doing almost every time - Flask is probably for you.
Are you a free software maintainer who is struggling with stress, demanding users, overwork, or any other social problems in the course of your work? Please email me — I know how you feel, and I can lend a sympathetic ear and share some veteran advice.
Articles from blogs I follow around the net
This post explains how to implement heap allocators from scratch. It presents and discusses different allocator designs, including bump allocation, linked list allocation, and fixed-size block allocation. For each of the three designs, we will create a ba…via Writing an OS in Rust January 20, 2020
This month's status update will be a little lighter than usual due to Christmas holidays. I've still got the chance to send a patches to quite a few projects, and… do a lot of releases! Weston, Wayland, Sway, mako and grim all have or will get a r…via emersion January 16, 2020
Inspired by Peter Watts’ The Freeze-Frame Revolution and The Island. Each birth is violent in the same way. I erupt into the void, my mirrored surface riotous with gamma radiation, parafluid sheeting from my forced extremities, ripped away by gravitational sh…via Aphyr: Posts January 15, 2020
Generated by openring