Just from my personal experience, I see django as a good "batteries included" solution that lets you get something up and running quickly because it gives you all the pieces in one package.  But I've found that I tend to actually use very little of it.

I tend not to use the django database/model stuff.  On my one large-scale django project, we used mongodb with mongoengine for the ORM layer.  On spi-tools, I'm using redis.

I've totally sworn off django templates in favor of Jinja, even at the cost of breaking some of the neat test client tools django supplies.

I kind of like django's middleware system, but in practice I find it a little too complicated, mostly because django doesn't provide a good way to pass around per-request context.  So you end up shoving your own data into django's HttpRequest, which is kind of evil.  Or you use thread local storage, which always seems a little sketchy.  Flask at least attacks the problem head-on by providing you with an explicit global object to use.  It may be thread locals under the covers, but at least it's officially supported.

I like Flask's decorator-based routing better than Django's url.py system.

But, with all that, I've got a few production Django systems under my belt and have only just toyed with Flask enough to get a feel for how it works.

I assume the plan is to do this in Toolforge?  There's a few things about Toolforge that I bristle at, but it does give a lot of value in the stuff you get for free.  I don't see any viable alternative for a small project like this.


On Sep 7, 2022, at 4:23 AM, Slavina Stefanova <sstefanova@wikimedia.org> wrote:

I appreciate suggestions on the tech stack we end up going with.