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.