Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move from Flask to FastAPI for the API #2567

Open
1 of 2 tasks
Venefilyn opened this issue Oct 4, 2024 · 0 comments
Open
1 of 2 tasks

Move from Flask to FastAPI for the API #2567

Venefilyn opened this issue Oct 4, 2024 · 0 comments
Labels
area/other Related to some other area/category than the specified ones. complexity/single-task Regular task, should be done within days. kind/internal Doesn't affect users directly, may be e.g. infrastructure, DB related.

Comments

@Venefilyn
Copy link
Contributor

Venefilyn commented Oct 4, 2024

Description

Since we only make use of Flask for the API we consider using something that is built for API development. I propose using something like FastAPI for two reasons:

  • Larger community that seems to be more long-term sustainable than Flask and its plugins
  • Gets us closer to something built for async rather than patched in later

There are some huge changes that would need to be addressed

  • FastAPI is using Pydantic for their models and data validation, which can be paired with SQLAlchemy using SQLModel
  • FastAPI is primarily an ASGI app, compared to Flask which is WSGI
  • Figure out how to handle API versioning and what actual implementation differences there would be to change

However there is an option that we can utilize to have a gradual move

  • We can for now hardcode WSGI and mount Flask as a middleware for a specific endpoint (i.e. keep Flask running on /api/ and running FastAPI on /api/v1 and /api/nightly/ or something similar

Benefit

Importance

Medium-High importance

Gives us two main impactful things that is otherwise difficult to handle in the current server and API

  1. Documented endpoints with a greater flexibility on how endpoint data is structured, which gives us a chance to avoid modifying requests like we currently do and instead put that into the model
  2. Async and WebSockets -- Currently this is difficult to do in Flask and with WebSockets not being a first-class citizen it becomes a weird way to write WebSocket support

As well as forcing us to make good API decisions regarding versioning, and proper pagination structure

What is the impacted category (job)?

General

Workaround

  • There is an existing workaround that can be used until this feature is implemented.

Participation

  • I am willing to submit a pull request for this issue. (Packit team is happy to help!)
@Venefilyn Venefilyn added the kind/feature New feature or a request for enhancement. label Oct 4, 2024
@nforro nforro added complexity/single-task Regular task, should be done within days. area/other Related to some other area/category than the specified ones. kind/internal Doesn't affect users directly, may be e.g. infrastructure, DB related. and removed kind/feature New feature or a request for enhancement. labels Oct 7, 2024
@nforro nforro moved this from new to backlog in Packit Kanban Board Oct 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/other Related to some other area/category than the specified ones. complexity/single-task Regular task, should be done within days. kind/internal Doesn't affect users directly, may be e.g. infrastructure, DB related.
Projects
Status: backlog
Development

No branches or pull requests

2 participants