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

Evaluate Migration from Flask to FastAPI #773

Closed
10 tasks done
lasryariel opened this issue Aug 30, 2024 · 3 comments
Closed
10 tasks done

Evaluate Migration from Flask to FastAPI #773

lasryariel opened this issue Aug 30, 2024 · 3 comments
Assignees
Labels
Complexity: Large Issue requires some research and solution is only loosely defined. Feature: Infrastructure Changes to site technical Architecture points: 2 Can be done in 7-12 hours Role: Back End

Comments

@lasryariel
Copy link
Member

lasryariel commented Aug 30, 2024

Overview

We are exploring the migration from Flask to FastAPI to improve code readability and make it more accessible for junior developers. This issue outlines the tasks needed to evaluate this transition.

Action Items

  1. SQL Alchemy Integration Analysis

    • Compare SQL Alchemy integration in Flask vs. FastAPI.
    • Assess object serialization with Marshmallow (Flask) vs. Pydantic (FastAPI).
  2. Object Serialization Review

    • Evaluate differences between Marshmallow and Pydantic.
    • Determine the ease of transition, especially for junior developers.
  3. Codebase Accessibility

    • Investigate how FastAPI can improve code readability.
    • Assess benefits for junior developer onboarding and contribution.
  4. Performance and Compatibility Check

    • Research performance improvements, especially with async operations.
    • Identify potential issues with Flask extensions and required refactoring.
  5. Decision Record

Resources/Instructions

@lasryariel lasryariel added Role: Back End Feature: Infrastructure Changes to site technical Architecture points: 2 Can be done in 7-12 hours Complexity: Large Issue requires some research and solution is only loosely defined. labels Aug 30, 2024
@tylerthome
Copy link
Member

From what have I seen so far in the FastAPI docs, there will be a lot of additive functionality we can take advantage of at the Pydantic level.

My main concern at this point is whether we need to stick with Pydantic v1 -- the docs didn't make this part clear

From this page in the docs:

These docs are about to be updated. 🎉

The current version assumes Pydantic v1, and SQLAlchemy versions less than 2.0.

The new docs will include Pydantic v2 and will use [SQLModel](https://sqlmodel.tiangolo.com/) (which is also based on SQLAlchemy) once it is updated to use Pydantic v2 as well.

@johnwroge can we confirm if this is just referring to the documentation being updated to Pydantic V2, or if their bindings to SQLAlchemy via SQLModel are still only available for <V1 pydantic?

A quick sample app could help confirm that the example code on that page works if we only install Pydantic >= 2, (replacing any calls in example Pydantic code from .dict() to .model_dump())

Inclined to say that we should be OK to move forward with v2, given that the example app @erikguntner shared seems to use it

@johnwroge
Copy link
Member

johnwroge commented Sep 3, 2024

Hi @tylerthome

I created a small sample app using FastAPI and the latest version of the framework is using Pydantic 2.8 and SQLAlchemy 2.032 which is the current version we are using. I don't think the bindings are being updated, the note seems to be there because the documentation is being updated and there won't be any breaking changes. .dict() and .model_dump() are both supported althought .dict() is deprecated.

In the example code the .dict() is used in a single method in create_user_item() in crud.py and it works with both .dict() and .model_dump(). VS code also notified me of the change too. I think we will have to use SQLModel too with Pydantic and SQL Alchemy. I haven't looked into if this will change anything, but I'll do this before the meeting tomorrow.

@lasryariel
Copy link
Member Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Complexity: Large Issue requires some research and solution is only loosely defined. Feature: Infrastructure Changes to site technical Architecture points: 2 Can be done in 7-12 hours Role: Back End
Projects
Status: Done
Development

No branches or pull requests

3 participants