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(a)wikimedia.org> wrote:
I appreciate suggestions on the tech stack we end up going with.