[tiangolo]

I'm glad FastAPI is useful! And thanks to InvestSuite for being one of the FastAPI gold sponsors.

If you are having problems, you can ask in GitHub issues.

But for the async stuff, a simple rule of thumb is to always use normal def functions and blocking (non async) libraries, that way FastAPI will do the right thing and make sure to run it in a threadpool (thanks to Starlette, the underlying library).

And for the specific path operations (endpoints) where you need to optimize performance, then you can use async and carefully choose async libraries, or run the blocking code with run_in_threadpool, but you can leave those details and possible extra complexity for the cases that actually need the extra performance or async support.

[ericdevries]

We use fastapi in production too, but the problem we faced with sync stuff in combination with sqlalchemy was that the sessions (which we inject using Depends) were created before all the actual sync functions were executed, so the connection pool ran dry and everything became unresponsive. With flask I had a better experience because it creates the session in the same thread as the function that will handle the request. If you overload it a bit (say, 100 concurrent requests with a connection pool of 30) all the Depends calls will block because there are no threads left in the pool to actually handle the requests.

I understand that fastapi is more suited for async stuff for which it truly works great, but it would be nice if there was a idiomatic solution within fastapi and/or starlette that prevents these kind of problems.

Great work otherwise!

[tiangolo]

Thanks, it would be great if you could create an issue with a simple way to replicate the problem so that I can check it out properly.

[advance512]

Any plans for gevent compatibility?