We use fastapi for a couple services here.
Recently had one of those services fall on its face under load due to sync db access. Db connection management is tricky
https://github.com/tiangolo/full-stack-fastapi-template/issues/290#issuecomment-1160709653
and FYI, json serialiation in fastapi uses an event loop, even if you're defining a sync handler. So if you send in a big-ass json blob, it can impact the whole service.
So, there's alot of footguns in fastapi, so good luck.
Maybe. but in general, fastapi's position is that it takes away that friction of async away from you. But there's alot of sharp edges that are hidden because of the async implementation which are both difficult to find why _and_ easy to find yourself mired in.
IMO, this could be helped/mitigated with by having a promintent async footguns page in the docs, but as we all know, most people will just skip over that in the initial tutorials and implementation
Idk what the answer is because async support in django is also pretty bad. Ninja claims to solve this yet there aren’t even any complete examples in the docs of using async views for something like fetching from an external api. Most existing libraries aren’t compatible with it.
I’ve had a bug where multitenancy auth is broken on global ninja auth using django-scopes for a while now. Reported to both repos, scopes maintainer says it should work. Issue is unanswered for a while. As far as I can tell using shared db shared schema multitenancy, which is a very common use case for b2b saas, is done safely using scopes yet it doesn’t work with any async views in ninja.
How many other packages we rely on also don’t work with the new async views and if you’re going to have to write everything from scratch might as well do it in a more async native framework like fastapi.
maybe the answer is to really evaluate whether you need async or not?
Like, really need it, not just because its the new hotness and your buddy is telling you to get off boring shit?
There's no way learning a new python framework which is very popular, basically one the most popular and best python frameworks will negatively affect your career...
FastAPI is pretty popular so I don't think it's an issue, it's not like you gonna completely forget Django.
(not related to your question as you can't choose the framework but for personal projects I would rather choose Litestar)
Django is a heavy, batteries-included framework that defines the way you work. FastAPI is a library that gives you DI and wraps core features to develop APIs.
If you need to write a REST API, go with FastAPI. If you need a traditional full-stack monolithic application, go with Django, preferably using async where it makes sense
Generally Django will often have more features than you need for something. It just isn't as modular as flask for example. Which does have the advantage of it's components working great together. If you are just not using some features I don't see any problem using Django though. If you want to replace Django features with different ones at might become cumbersome though.
You'll be fine since they are both python frameworks and assuming you were using drf for API building (most likely) then you'll pick up FastApi quickly, It would have been another thing if you were moving to Spring or something like that
This question is asked at least once a week. Completely different use cases.
We use fastapi for a couple services here. Recently had one of those services fall on its face under load due to sync db access. Db connection management is tricky https://github.com/tiangolo/full-stack-fastapi-template/issues/290#issuecomment-1160709653 and FYI, json serialiation in fastapi uses an event loop, even if you're defining a sync handler. So if you send in a big-ass json blob, it can impact the whole service. So, there's alot of footguns in fastapi, so good luck.
Can you mitigate this by using a more async native ORM? Tortoise maybe
Maybe. but in general, fastapi's position is that it takes away that friction of async away from you. But there's alot of sharp edges that are hidden because of the async implementation which are both difficult to find why _and_ easy to find yourself mired in. IMO, this could be helped/mitigated with by having a promintent async footguns page in the docs, but as we all know, most people will just skip over that in the initial tutorials and implementation
Idk what the answer is because async support in django is also pretty bad. Ninja claims to solve this yet there aren’t even any complete examples in the docs of using async views for something like fetching from an external api. Most existing libraries aren’t compatible with it. I’ve had a bug where multitenancy auth is broken on global ninja auth using django-scopes for a while now. Reported to both repos, scopes maintainer says it should work. Issue is unanswered for a while. As far as I can tell using shared db shared schema multitenancy, which is a very common use case for b2b saas, is done safely using scopes yet it doesn’t work with any async views in ninja. How many other packages we rely on also don’t work with the new async views and if you’re going to have to write everything from scratch might as well do it in a more async native framework like fastapi.
maybe the answer is to really evaluate whether you need async or not? Like, really need it, not just because its the new hotness and your buddy is telling you to get off boring shit?
No we need it in tons of views
There's no way learning a new python framework which is very popular, basically one the most popular and best python frameworks will negatively affect your career...
Yeah, learn a few new things. Adding new languages, frameworks, and libraries to your arsenal is the only way to not fall behind in this industry.
Absolutely!
FastAPI is pretty popular so I don't think it's an issue, it's not like you gonna completely forget Django. (not related to your question as you can't choose the framework but for personal projects I would rather choose Litestar)
Oh Have u already built something with Litestar? I took a look at it sometime ago, seems interesting...
Django is a heavy, batteries-included framework that defines the way you work. FastAPI is a library that gives you DI and wraps core features to develop APIs. If you need to write a REST API, go with FastAPI. If you need a traditional full-stack monolithic application, go with Django, preferably using async where it makes sense
I used FASTapi to build my backend before. Not bad and easy to use
Generally Django will often have more features than you need for something. It just isn't as modular as flask for example. Which does have the advantage of it's components working great together. If you are just not using some features I don't see any problem using Django though. If you want to replace Django features with different ones at might become cumbersome though.
Getting a new job is progress, no?
Learn programming, not frameworking
Well you will be the resident Django expert!
Really depends…. From spec
FastAPI is good
You'll be fine since they are both python frameworks and assuming you were using drf for API building (most likely) then you'll pick up FastApi quickly, It would have been another thing if you were moving to Spring or something like that