aio-libs
ASGI support
Is your feature request related to a problem?
As far as I know most async Python web frameworks nowadays use ASGI with servers like Uvicorn. However, as far as I can tell aiohttp server does not support ASGI.
Describe the solution you'd like
It would be nice if aiohttp could support ASGI, so that it can benefit from features provided by ASGI web servers (see for example https://github.com/aio-libs/aiohttp/issues/5999#issuecomment-930626734).
There may also be some performance benefits to ASGI over WSGI, but I don't know enough about the internals of how aiohttp interfaces with WSGI to make specific claims about this.
Describe alternatives you've considered
Aiohttp isn't fundamentally broken without this feature so doing nothing is always an alternative.
Related component
Server
Additional context
There was pervious discussion of this in 2018 (https://github.com/aio-libs/aiohttp/issues/2902). The final decision there seemed to be to wait and see. Since then ASGI has become much more stable and much more widely used, so I think it is time to revisit this decision.
Code of Conduct
- [X] I agree to follow the aio-libs Code of Conduct
There may also be some performance benefits to ASGI over WSGI, but I don't know enough about the internals of how aiohttp interfaces with WSGI to make specific claims about this.
We don't support either... (a quick search suggests it wouldn't even be possible to support WSGI as it's sync only). The discussion you linked to Andrew even says that performance may be lower with ASGI: https://github.com/aio-libs/aiohttp/issues/2902#issuecomment-377925008 https://github.com/aio-libs/aiohttp/issues/2902#issuecomment-419906320
I think, as per those previous discussions, I don't see any major advantages to implementing this, and so I doubt anyone here will want to invest time into it. However, if someone wants to give it a go, we'll consider merging it. If the integration is a simple as the attempt in 2017, then it looks reasonable: https://github.com/aio-libs/aiohttp/pull/2035/files (I suspect though, that it will result in losing some features and creating some compatibility issues...)
We don't support either... (a quick search suggests it wouldn't even be possible to support WSGI as it's sync only).
I might have misunderstood something then. I noticed that aiohttp supports Gunicorn (https://docs.aiohttp.org/en/stable/deployment.html#nginx-gunicorn) and assumed that since Gunicorn is a WSGI server aiohttp somehow uses (or abuses) WSGI to communicate with Gunicorn.
OK, Gunicorn integration is it's own thing: https://github.com/aio-libs/aiohttp/blob/master/aiohttp/worker.py I'm not familiar with how Gunicorn works. Though that code looks like it still sets up the usual runner/server, so I don't see how it'd be integrating with WSGI (maybe it's able to use Gunicorn as some kind of worker manager without the WSGI integration?).
Yes, the docs compare it with supervisord. I think it just let's one have parallelism through multiple processes. There's no WSGI because those standards were created way before asyncio was a thing (PEP 333 — 2003 / PEP 3333 — 2010). The HTTP servers would load WSGI importables once (per process) and keep calling them for each request. They would take care of parsing HTTP and the WSGI frameworks would be able to focus on the application logic. These servers with WSGI interfaces are usually written in compiled languages (Apache, nginx etc) and so their HTTP parsers are more performant than the pure-python ones. It made sense not to have the HTTP server part written in Python (though, such projects exist too — Cheroot, waitress to name a few).
My understanding is that ASGI is an attempt to reinvent it for async interfaces. However, aiohttp's HTTP parser is a C-extension so perhaps that's the reason Andrew thought it would have a performance hit for aiohttp-based apps — because of an extra layer of indirection and having our parser replaced with a potentially slower one. Note that it was when we were relying on the different underlying parser implementation and things may be slightly different post migration to llhttp, but I wouldn't expect it to be noticeable.
Whoever ends up working with this should also make and document a performance comparison. I'm not necessarily against the implementation, provided it isn't contributed in a way that brings a lot of maintenance burden. It'd also have to be fully covered with tests.
