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

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.