Tech stack for Python aurweb

[Lukas Fleischer]

Thank you for your comments Ricardo and Baptiste.

On Tue, 02 Jun 2020 at 09:07:21, Baptiste Jonglez wrote:
> I generally don't like the kind of comments that go "it would be nicer if
> you do X and Y" from people that won't actually participate, but I still
> feel it's relevant:

One of the reasons for starting this thread was to give non-core
developers the opportunity to step in and make alternative proposals or
raise concerns, so no need to worry about that.

> On 24-05-20, Ricardo Band wrote:
> > I'm a python programmer for a while now and I really like the small
> > size and simplicity of Flask. But let me give you one advice here.
> > If you're dealing with a more complex application Flask tends to become
> > more complex and very hard to manage. All of a sudden you integrate
> > about 10 Flask addons. Some of them are not well maintained. Some
> > droppen support for others etc.
> > You have to manage all those dependencies.
> > 
> > Personally I prefer Django in more complex projects as it comes with
> > everything included. You rarely have to add something to your
> > dependencies.
> 
> I completely agree with this.
> 
> Flask is fantastic for simple projects.  But once you start adding users,
> authentication, an admin panel, command-line scripts, and so on, it
> quickly becomes a mess.  Django is much more structured, which is a big
> advantage for complex projects.

One thing I should have clarified much more in my first email in this
thread is that this is part of a dual stack solution, with most of the
code still being written in PHP and only specific pages being handled by
the new framework. Everything we do (including database access, user and
session management, ...) must be fully compatible with our PHP
implementation, hence we would almost certainly not be able to use any
of the more sophisticated features that these more comprehensive
frameworks provide.

> Regarding databases and migrations, Django is much nicer to work with than
> SQLAlchemy / Flask-SQLAlchemy.  For instance, with Flask-SQLAlchemy I've
> had serious consistency issues between PostgreSQL and Sqlite, something
> that I had never seen with Django.

Same here, everything needs to be compatible with our existing PHP code
base; and we're already using SQLAlchemy for migrations there (even
though this would be not too hard to change at this point if there is a
strong reason for doing so).

> Also, the Flask ecosystem is not exactly bustling with activity.  On the
> positive side, this is because things are remarkably stable and working as
> intended.  On the negative side, it means some amount of bit-rot and
> unmaintained projects, although it's clearly not to the point of complete
> disrepair.

As you may have noticed from some of the patches submitted to the ML, we
decided to use FastAPI over Flask.

Best regards,
Lukas