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 <[email protected]> > wrote: > > I appreciate suggestions on the tech stack we end up going with.
_______________________________________________ Wikitech-l mailing list -- [email protected] To unsubscribe send an email to [email protected] https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
