More on ASGI (Python's asynchronous version of WSGI for HTTP2)
Lassi Kortela 09 Jul 2019 12:35 UTC
Amirouche brought ASGI to our attention in April.
From the docs
<https://asgi.readthedocs.io/en/latest/introduction.html>, the
fundamental abstraction is:
> async def application(scope, receive, send):
> event = await receive()
> ...
> await send({"type": "websocket.send", ...})
>
> Every event that you send or receive is a Python dict, with a
> predefined format. It’s these event formats that form the basis of the
> standard, and allow applications to be swappable between servers.
>
> These events each have a defined type key, which can be used to infer
> the event’s structure. Here’s an example event for sending the start
> of a HTTP response that you might get from receive:
>
> {
> "type": "http.response.start",
> "status": 200,
> "headers": [b"X-Header", b"Amazing Value"],
> }
Apparently Python has now got async/await in the base language.
ASGI is protocol agnostic; here's the spec for how HTTP is done:
<https://github.com/django/asgiref/blob/master/specs/www.rst>.
Here's a real implementation of CORS middleware:
<https://github.com/encode/starlette/blob/master/starlette/middleware/cors.py>.
It's getting quite complex compared to the simple request/response API
of WSGI and other traditional request abstractions. Should we just write
a SRFI to standardize the traditional abstaction quite soon? It's likely
that people will still want to use it for years in the future, because
it's much simpler than the asynchronous stuff, and the async stuff is
backward-compatible with the traditional abstraction (e.g. one can make
an ASGI wrapper for a WSGI request handler).