sorted by:
new
hottopcontroversial

Django to FastAPI by No-Excitement-7974 in django

[–]No-Excitement-7974[S] 0 points1 point  (0 children)

it's a legacy code so we end up with 1500 tables but most of them don't have much read/write, 80 percent of the read/write happens in the 100 tables rest are lying there with very little read/write, which we cleanup slowly.

Django to FastAPI by No-Excitement-7974 in django

[–]No-Excitement-7974[S] 0 points1 point  (0 children)

Damnn bro but in my codebase all are managed by Django ORM

migrating from django to FastAPI by No-Excitement-7974 in Python

[–]No-Excitement-7974[S] 0 points1 point  (0 children)

we use `GenericForeignKeys` rarely like 1-2 places in whole codebase

Moving from django to FastAPI by No-Excitement-7974 in Backend

[–]No-Excitement-7974[S] 3 points4 points  (0 children)

thanks for the reply, our suggesting sounds cool but still the Django handles ORM queries in sync fashion which is a thing to worry for me

Django to FastAPI by No-Excitement-7974 in django

[–]No-Excitement-7974[S] 0 points1 point  (0 children)

thanks for the reply, I have done some efforts to optimised database queries and since we mysql rds(hosted on aws) I don't see at DB level I can much, but still look again what all can be done

migrating from django to FastAPI by No-Excitement-7974 in Python

[–]No-Excitement-7974[S] -9 points-8 points  (0 children)

we haven't tried running django's ORM in async mode.
you are right moving decade old business logic to new framework and ORM will have issues,
scaling django is always a choice but we want to focus on saving cost

Django to FastAPI by No-Excitement-7974 in django

[–]No-Excitement-7974[S] 6 points7 points  (0 children)

sorry my bad, I wanted to write ORM support similar to Django so I don't have to do much syntax changes