[socialist_coder]

"When you don't need it"

If you're doing any kind of database / external network calls - won't you gain a huge amount of requests per second?

I ask partly because on one of my projects, we have a fastapi app, but it's not using async, and I have been toying with the idea of converting it to async. It will take some work though because it uses libs that don't support async.

I thought the advantages would be worth it because we hit postgres and/or redis on all requests.

[kissgyorgy]

The only reasonable use case for asyncio is an API gateway or similar, when you issue a huge amount of HTTP requests, do very little CPU intensive tasks and waiting for I/O all the time.

Any other use-case you are better off going with the simplicity of a sync framework like Flask. For databases you are way worse with async, see why from the Python database god himself: https://techspot.zzzeek.org/2015/02/15/asynchronous-python-a...

[ekimekim]

Flask has historically been used in combination with gevent/eventlet which are greenthreaded async frameworks that predate python's async/await support. These still work and are still a great choice for an async server with many concurrent requests. The big downside is just lack of compatability with the new async ecosystem.

[digisign]

The usecase for async is spidering web pages or keeping a thousand chat sockets up, not for talking to a local database.

[323]

I think I'm in a similar situation with you, and asyncio has been great.

Not sure what libs you use, you'll probably need to switch libraries, it's not common for one lib to support both sync/async. I'm using aiohttp for http/websockets and asyncpg for postgres, running on uvloop as the base event loop.

Something which is trivial with asyncio: I receive 10 consecutive heavy websockets requests, I spawn a task to handle each one of them and they will be served back out of order as Postgres returns results. With no locking or messing with threads.

Another benefit is knowing for certain your code won't be interrupted unless you call "await", this simplifies a lot using shared state without requiring locks.

[mattclarkdotnet]

Why not run multiple processes? This has been the way for over 20 years.

[smackeyacky]

Green Unicorn and the like do this and do it very well.

[floober]

Flask is a multi-threaded server, so while only one thread can execute Python code at a time (due to the GIL), you still get concurrency with respect to IO. Not to say that e.g. FastAPI won't get you more RPS, but it may or may not be as dramatic as you would expect.

[aeyes]

> If you're doing any kind of database / external network calls - won't you gain a huge amount of requests per second?

Only if they can be parallelized. I'm not sure if I would choose Flask if I had such a complex application.