As a dev, I want to explore alternative web frameworks to Flask for improved performance and developer experience

[k-allagbe]

Description

Context
Currently, we use Flask to build our APIs. While Flask has been sufficient, it is synchronous and lacks some modern features like built-in asynchronous support and automatic API documentation (OpenAPI/Swagger). There are other open-source frameworks that could better suit our needs by offering enhanced developer experience and feature sets. We are considering alternatives like FastAPI, Quart, and others that meet our criteria, but only open-source solutions will be considered.

Problem Statement
Flask’s synchronous nature and lack of modern tooling (like automatic async support and Swagger generation) requires extra effort from developers. Evaluating other open-source frameworks that offer these features could improve the developer experience, streamline API development, and potentially enhance performance. While Django is excluded for being too heavyweight and opinionated for our use case, there may be other alternatives beyond FastAPI and Quart worth exploring.

Acceptance Criteria

• Research and compare various open-source web frameworks (including but not limited to FastAPI and Quart) with respect to developer experience, feature set, ease of use, and scalability.
• Evaluate async capabilities, API documentation support (OpenAPI/Swagger), and community support.
• Document potential migration challenges from Flask to any alternative framework.
• Provide a well-reasoned recommendation, outlining the pros and cons of each alternative, and the potential benefits to the team.

Additional Information

• Python devs survey 2023 results
• How I compare FastAPI with Flask/Quart by Philip Jones author of Quart

[snakedye]

https://github.com/timofurrer/awesome-asyncio?tab=readme-ov-file#web-frameworks

[k-allagbe]

I suggest moving the comparison into this repository instead of making it an ADR.

[snakedye]

@k-allagbe
So far I'm stuck at the tests. It's good that the requests are typed but the types in each fields are hard to find.
With more work I could find them and have something more robust and idiomatic but rn I jsut use the header.

I see a lot of good API wise but it definitely requires some work to mimic what we have in Flask. It's definitely an extra burden on the team and a new set of skills and knowledge. I don't think we can ask nachet to migrate to it.

[k-allagbe]

The objective was definitely not to impact nachet.

It's definitely an extra burden on the team and a new set of skills and knowledge.

Evidently. Different tools. Please report that in the doc. I will take a crack at it too see if we can come up with something not too far from familiarity.

[snakedye]

So far with the Quart port, the API isn't that much different with the exception of anything related to authorization. flask_httpauth has a Quart equivalent but it doesn't appear to be as well maintained so I went with quart_auth.
The main issue with it is that it doesn't really follow the same flow, even with Basic auth, as what we currently use. It's not necessarily a problem considering ai-cfia/fertiscan-backend#163 but just some food for thought.

Also whether or not we go with FastAPI or Quart, the connection manager will need to be refactored as it's not compatible with async.

[k-allagbe]

Moving this to dev-rel-docs.

[k-allagbe]

Closing this as done.