It's hard to distinguish signal from noise in responses to these posts without knowing context of how long people have used fastapi in their system, was it used in production vs a hobby project, what interesting limitations or failure modes did they learn after going into production.
I've used fastapi for less than one month, to bash out an API for a simple service, in a commercial environment that doesn't have high load requirements or value software quality.
What i like: auto generated API docs, declaring types (not as good as language with static type system, but OK for python ), automatic validation of request/response payloads.
What i'm skeptical of: fastapi forces me to use asyncio but my service doesn't have a problem where asyncio helps, fastapi's bespoke dependency injection system -- started to immediately feel awkward when i wanted to write some custom middleware, fastapi encourages you to structure apps with a bunch of global state & then write tests by monkey-patching that global state in test harnesses (more a style mismatch, not a blocking problem).
What's actually been a serious problem: haven't been using it long enough in production to have an opinion.
We used Python as we had a bunch of existing business logic in Python we wanted to re-use, we're prioritizing "can it exist and be integrated very quickly" over other concerns such as scalability or long term maintenance costs or software supply chain concerns. If we were starting from a clean slate with no Python code, Python + FastAPI isn't obviously a superior choice to go + go standard http library + chi router.
Agreed, flask is nice for a student who wants to handroll a lot of code as a learning experience, but you end up reinventing the wheel unnecessarily IME. The library ecosystem for flask seems quite fractured which doesn't help.
I would say so, although you're encouraged to use a lot of async libs which can be a pain in the ass to debug. Flasks ecosystem seemed filled with half-abandoned libraries last time I checked (2021).
A little concerned about FastAPI’s low bus factor, and the docs being only example-driven rather than reference docs gets occasionally annoying, but other than that it’s been nice and we aren’t regretting running it in prod.
I've used fastapi for less than one month, to bash out an API for a simple service, in a commercial environment that doesn't have high load requirements or value software quality.
What i like: auto generated API docs, declaring types (not as good as language with static type system, but OK for python ), automatic validation of request/response payloads.
What i'm skeptical of: fastapi forces me to use asyncio but my service doesn't have a problem where asyncio helps, fastapi's bespoke dependency injection system -- started to immediately feel awkward when i wanted to write some custom middleware, fastapi encourages you to structure apps with a bunch of global state & then write tests by monkey-patching that global state in test harnesses (more a style mismatch, not a blocking problem).
What's actually been a serious problem: haven't been using it long enough in production to have an opinion.
We used Python as we had a bunch of existing business logic in Python we wanted to re-use, we're prioritizing "can it exist and be integrated very quickly" over other concerns such as scalability or long term maintenance costs or software supply chain concerns. If we were starting from a clean slate with no Python code, Python + FastAPI isn't obviously a superior choice to go + go standard http library + chi router.