4 ms·
We need to write a lot of small APIs in Python for SPAs. We ended up going with FastAPI which utilizes Starlette under the hood. I'm surprised neither of them a
by hmcdona1 7y ago
We need to write a lot of small APIs in Python for SPAs. We ended up going with FastAPI which utilizes Starlette under the hood. I'm surprised neither of them are mentioned here.
Starlette was developed by the same dev who wrote the Django RESTful package. If you mostly just need REST APIs or even GraphQL, it feels far more light and modern than anything in Django and forms some better opinions around things than the usual roll your own stack in flask alternative. Not to mention it's ASGI based instead of WSGI and naturally faster because of it.
FastAPI just builds on that by adding some nice features like minimal dependency injection and really awesome integration with type hints via Pydantic.
- heyoni 7y agoDo frameworks need to be asynchronous or is it good enough to just spawn threads for background tasks?
- hmcdona1 7y agoasync is more beneficial for when code is primarily network bound. WSGI is thread based which comes with a higher overhead for task switching. So it’s just not as efficient for most web server tasks.
- heyoni 7y agoOk I think I get it, but if your backend is say, making a single API call and sending that result back to the user, then there's no advantage to going async since the user has to wait for that network call anyways, right? Would you use this async then in instances where some of the API calls don't matter to your user?
- cle 7y agoI don’t know about Starlette/FastAPI, but generally a true async server could still see a benefit, because while that downstream call is blocked waiting on a response, the OS thread can switch to a different request. This is in contrast to a more traditional one-OS-thread-per-request model, where each thread spends the vast majority of its time waiting on I/O. If your work is I/O bound you can use expensive OS threads much more efficiently. Depends on your workload characteristics and requirements.
- BlackFly 7y agoPython wsgi servers are generally based on processes and not threads since threads would trigger GIL considerations. While your process is making the single API call, the process is not serving anyone else, ergo you can only have so many simultaneous requests in flight as you have workers. Threads have no benefit over asyncio in python due to the GIL and have costs over ascyncio due to setting up the thread context with the OS. With asyncio based implementations, while the coroutine is waiting for the response on the API call, the process's event loop can check on the coroutine which is handling the network socket and start processing another request. Ideally it should have no impact on the amount of time the original request takes to process but you can see how it might since when the API call resolves, the process may be working on the other request instead of continuing with the original coroutine. Asynchronous code in general can allow you to extend your bandwidth past the number of concurrent executions your program can maintain (whether they be processes in python or threads in other languages) by doing additional work while it is waiting for something to complete. Ideally it should not cost much in terms of latency.
- pencilcode 7y agoWithout going asyncio you can always use greenlets and get the same benefits. Using uwsgi with gevent makes it easy.
- bayesian_horse 7y agoAsynchronous IO is really good at doing nothing, especially doing multiple nothings in parallel.
- deleted 7y ago[deleted]
- dwaltrip 7y agoFrom what I remember from my research and readings, asyncio based python web servers are _not_ automatically faster than non-asyncio python web servers.