Why I chose Flask to build sr.ht's mini-services January 30, 2019 on Drew DeVault's blog

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:

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:

And to summarize the good:

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.

Articles from blogs I read Generated by openring

Robust generic functions on slices

Avoiding memory leaks in the slices package.

via The Go Blog February 22, 2024

ClassNotFoundException: java.util.SequencedCollection

Recently I’ve had users of my libraries start reporting mysterious errors due to a missing reference to SequencedCollection, a Java interface added in JDK 21: Execution error (ClassNotFoundException) at jdk.internal.loader.BuiltinClassLoader/loadClass (Buil…

via Aphyr: Posts February 20, 2024

Status update, February 2024

Hi! February is FOSDEM month, and as usual I’ve come to Brussels to meet with a lot of other FOSS developers and exchange ideas. I like to navigate between the buildings and along the hallways to find nice people to discuss with. This edition I’ve been invol…

via emersion February 20, 2024