Async python is not inherently "faster" than sync, more scalable? maybe, easer to write parallel code? yes. But async does not magically make anything faster.
> synchronous and needs multiprocess deployment
Async python still has the issue of the GIL, you still need multiple processes to scale out with async.
The only seriously useful thing async gives you is the ability to run multiple async IO operations in parallel while processing a single request. But most async request processing is still being written in a somewhat sync way, "awaiting" each IO operation within a view/request processing function.
I tend to only use async for long running requests (web-sockets, SSE, long polling), or if I have a view that is calling lots of slow IO which doesn't depend on each other. Think views that are calling multiple REST APIs, and multiple DB requests, you can do them all at once. That is incredible rare though, usually requests do depend on each other and so have to be run sequentially.
Yes, sorry didn’t mean to suggest you didn’t. Comment was more to clarify to others as the simplistic “it’s faster” can cause people to misunderstand the nuance, which is important as the developer UX of async is worse than sync. I believe we should stick to sync unless there is a significant reason not to.
The trouble with all these things is what the definition of faster is. If it’s “requests per second” then yes these async frameworks are incredible on these benchmarks with their somewhat simplistic view code (I haven’t looked in detail at the one linked, but many often are only echoing back a response).
Really for the vast majority of developers the speed that matters is “time to first meaningful paint” - the time it takes to get a webpage to display on the users browser, or for an api the time until the response is ready to be passed by your front end code. Async doesn’t increase the speed at which that will happen, except in some situations with heavily paralyzable IO within a view.
It is however true that you can get more out of your hardware with async if your are handling 10s or 100s thousands requests per second. Very few of us ever get close to that though.
(Again not suggesting you don’t know this, commenting for others)
Fair enough. Indeed - "fast" for async programs does not come out of vacuum. We just don't need to wait for IO (db, other http calls, whatever) which is common in web applications. Thus it "feels faster".
Though personally when I mentally imagine web frameworks "speed" - it is requests per second as well as getting better bang for your buck out of your hardware.
what you don't understand is that FastAPI is not a web framework, so it is neither fast nor slow, it's just a patchwork of libraries on top of Starlette.
Thanks for this detailed comment. I think people really misunderstand async python on web servers. Async literally only helps when you are io bound otherwise it hurts
> synchronous and needs multiprocess deployment
Async python still has the issue of the GIL, you still need multiple processes to scale out with async.
The only seriously useful thing async gives you is the ability to run multiple async IO operations in parallel while processing a single request. But most async request processing is still being written in a somewhat sync way, "awaiting" each IO operation within a view/request processing function.
I tend to only use async for long running requests (web-sockets, SSE, long polling), or if I have a view that is calling lots of slow IO which doesn't depend on each other. Think views that are calling multiple REST APIs, and multiple DB requests, you can do them all at once. That is incredible rare though, usually requests do depend on each other and so have to be run sequentially.