Do we want to continue to support Flask?

[jeancochrane]

Flask and Django both use Python but are substantially different frameworks. Currently, we support documentation and templates for both types of apps, although the Flask docs are used much less frequently (as far as I can tell we only have two active projects that are written in Flask, Dedupe.io and Parserator, both of which are legacy apps).

I'd love to have a conversation about whether or not it's a good idea for the company to continue to support Flask. If so, when are times that we would prefer to use Flask over Django? If not, what's our path forward for minimizing the maintenance burden of our Flask apps?

[hancush]

thanks for raising this, @jeancochrane! i think it's a really important question.

there are a few other (semi-)active projects written in flask:

• https://github.com/datamade/metro-pdf-merger
• https://github.com/datamade/property-image-cache
• https://github.com/datamade/the-misters-eds

plus a handful of legacy apps, including election transcriber, occrp, and illinois sunshine.

looking at both pic and the metro pdf merger, i think that flask is a much better fit for simple applications that listen for requests and then script some operation, e.g., combine files or cache documents in s3, and respond. perhaps there are more contemporary solutions, like lambda, that could accomplish this type of task. i'd be super into learning more there! otoh, i really value having a lighter weight tool in our primary development language, as it keeps the barrier to entry low for newer developers.

otoh, the eds is a layer on top of another application, so (for better or worse), it leveraged the underlying app's database, rather than requiring its own. this use case strikes me as mostly unconventional (https://github.com/datamade/ops/issues/364 🐴), but it was nice to have a lighter weight web framework rather than writing a django application and completely eschewing most of the functionality it came with.

i'll also note, if we win the metro etl dashboard sow, airflow is a flask app. for me, this would be a compelling enough reason for me on its own to keep flask in our standard stack.

[jeancochrane]

Some notes from our conversation today:

• Forest:
  • Dedupe.io is our biggest Flask app; we wish it was Django instead
    • Many Flask apps (including us) attempt to reimplement Django as they get more complex
  • Historically, it's not always clear up front how simple an application will wind up being
  • How hard is it to run a databaseless-app?
  • Serverless is another future possibility in the simple-API space
• Bea:
  • If BM were to be onboarded to Dedupe, Flask would steepen the learning curve
• Hannah:
  • Burden of two streams of documentation will be lower when we move to Heroku
  • HC just prefers Flask; there should be some wiggle room to allow for this too

Since we haven't developed a new client project in Flask in a while, this may be a moot point. A better approach than a hard-and-fast policy will be to open up a conversation about tradeoffs the next time someone wants to develop a new project in Flask.