ASGI from scratch – Let's build an ASGI web framework(shenli.dev)
shenli.dev
ASGI from scratch – Let's build an ASGI web framework
https://shenli.dev/2020/06/20/asgi-from-scratch.html
11 comments
I’m heavy user of quart and uvicorn. It’s a blessing of freshly air and f*ck perfomance, my workload down from 2048 pods to 512 just because of change from wsgi
Are there any benefits of this approach if no websockets are involved ?
According to some benchmarks, an ASGI framework will generally perform better than a WSGI framework [1].
Currently, the ASGI ecosystem isn't nearly as mature as the WSGI ecosystem, and for a production system, I would still prefer WSGI for now. Django just got ASGI support in 3.0, but it still has a long way to go to become fully asynchronous [2]. I think Starlette [3] will become a popular ASGI framework, but it's still early in it's development.
[1] https://www.techempower.com/benchmarks/#section=data-r19&hw=...
[2] https://docs.djangoproject.com/en/3.0/howto/deployment/asgi/
[3] https://www.starlette.io/
Currently, the ASGI ecosystem isn't nearly as mature as the WSGI ecosystem, and for a production system, I would still prefer WSGI for now. Django just got ASGI support in 3.0, but it still has a long way to go to become fully asynchronous [2]. I think Starlette [3] will become a popular ASGI framework, but it's still early in it's development.
[1] https://www.techempower.com/benchmarks/#section=data-r19&hw=...
[2] https://docs.djangoproject.com/en/3.0/howto/deployment/asgi/
[3] https://www.starlette.io/
Hi, YarickR2. I think if the whole application does not require interacting with other asyncio stuff then it's fine to stick to WSGI.
I like ASGI because it allows us to do some things (including websocket, asynchronous io, etc) much easier. And even it is not compatible with WSGI, it's not hard to wrap around a WSGI application.
The framework built in the post is far from finished or practical, please take a look at Starlette, FastAPI or even Django, etc to know more about the use cases of ASGI.
I like ASGI because it allows us to do some things (including websocket, asynchronous io, etc) much easier. And even it is not compatible with WSGI, it's not hard to wrap around a WSGI application.
The framework built in the post is far from finished or practical, please take a look at Starlette, FastAPI or even Django, etc to know more about the use cases of ASGI.
FastAPI is awesome. The way it joins data types with input validation and automatic reference docs generation is just great. Not to mention that their own docs are pretty comprehensive.
(not affiliated, just a happy user)
(not affiliated, just a happy user)
ASGI is meant to be used to enable asynchronous Python code. I guess there are many I/O bound server applications that can benefit from it.
It depends on the workload and app for sure, but in my experience, most of my services make a bunch of outgoing calls, usually HTTP, to different services, often in a single operation. Being able to do these in parallel, on the side, or via fork/join was pretty handy. For a simple Flask app that fronts a single db, sure, stick with wsgi, but I don't run into many apps like that anymore.
Maybe not, according to this: http://calpaterson.com/async-python-is-not-faster.html
All of the high performing results are running with servers written in C/C++ tho.
I think if we have a more performant ASGI server / event loop, the results might be different.
I think if we have a more performant ASGI server / event loop, the results might be different.