hackforla / HomeUniteUs

We're working with community non-profits who have a Host Home or empty bedrooms initiative to develop a workflow management tool to make the process scalable (across all providers), reduce institutional bias, and effectively capture data.
https://homeunite.us/
GNU General Public License v2.0
39 stars 21 forks source link

Evaluate Migration from Flask to FastAPI #773

Closed lasryariel closed 2 months ago

lasryariel commented 2 months ago

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

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

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

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

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

Resources/Instructions

tylerthome commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

Decision Record created: https://github.com/hackforla/HomeUniteUs/wiki/Migrating-from-Flask-to-FastAPI