A relatively small minority of web projects really benefit from async. There's a performance benefit that comes at the cost of going all-in on the async ecosystem andunless you have a very high-traffic website where hosting costs a significant part of your IT budget, or you need lower latencies or a few other situations it likely won't be worth 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.
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.
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.
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.
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.
> Does the lack of async still make Flask a good choice for non-hobby web projects?
[ed: the lack of async probably means little for how good flask is for a new project - it's a great little framework].
However, with the birth of fastapi - I would be hard pressed to name a greenfield project/situation where I would recommend flask over fastapi. And the support for async in fastapi have nothing to do with that.