Mental model
ASGI (Asynchronous Server Gateway Interface) is the async successor to WSGI, defining a standardized interface between async web servers (Uvicorn, Granian) and Python frameworks (FastAPI, Starlette).
Theory
An ASGI 3.0 application is a single async callable with signature app(scope, receive, send):
scope: Dictionary containing request metadata (HTTP method, headers, path).receive: Async function to receive incoming request body chunk events (http.request).send: Async function to transmit outgoing response events (http.response.start,http.response.body).
Alternatives and trade-offs
- WSGI (Gunicorn): Synchronous single-request-per-worker model. Fails at WebSockets or streaming.
- Uvicorn (uvloop + httptools): Async server using Cython bindings for libuv and C HTTP parser.
- Granian (Rust core): Rust-based ASGI/WSGI server using
hyperfor high throughput.
Failure modes and misconceptions
- WSGI Middleware on ASGI: Wrapping WSGI blocking middleware around FastAPI breaks asynchronous execution.
- Missing
http.response.body: Forgetting to send the body event leaves HTTP client connections hanging.
Decision scenario
Deploy production FastAPI applications with multi-worker ASGI process managers (Gunicorn + Uvicorn workers or Granian) to maximize async multi-core CPU throughput.
Learning outcomes
- Deconstruct the raw
app(scope, receive, send)ASGI specification callable. - Compare WSGI synchronous request lifecycles with ASGI asynchronous event channels.
- Deploy Uvicorn and Granian servers with optimal process worker topologies.
Trade-offs
ASGI servers support high-concurrency HTTP/WebSocket connections, but require non-blocking async architecture throughout all route handlers.