FastAPI is async web-framework for Python comparable [0] to Flask.
Read it as Flask is "old" and "slow" (i.e. synchronous and needs multiprocess deployment), whereas FastAPI is really fast, single threaded and async.
[0] IMHO comparable only at "hello world" level as FastAPI is much more and uses a lot of goodies of newer Python versions (typing, asyncio, etc.)
> 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.
I understand the pros/cons of async vs sync. Just did not want to get into multi-paragraph tirade to explain everything.
EDIT: though FastAPI is still fast compared to other python frameworks and especially synchronous ones: https://www.techempower.com/benchmarks/#section=test&runid=7...
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)
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.
Great writeup - I think we are on the same page.