This talk will take a look at how Django could look if it was designed from the ground up as an ASGI framework. We’ll examine how we could approach this design in a way that helps reduce tight coupling and framework complexity, and take a look at what new capabilities this would provide. This talk sketches out how a redesign of Django might look, if it was reworked as an ASGI web framework. It draws on the design work behind the Starlette web framework and the Uvicorn web server. Where we are now Overview of the fundamentals of the request/response flow in Django: WSGI, the Django middleware stack, and request routing. Introducing ASGI ASGI’s evolution. The ASGI interface. Capabilities that ASGI provides: Concurrency & performance, WebSockets, Server Sent Events, HTTP/2 Server Push, Background tasks. Startup / shutdown / clock events. Running threaded code in an ASGI context. Concurrency and database transactionality. An ASGI-centered design ASGI middleware vs. a middleware interface. Using ASGI middleware, but with a request/response interface. Routing as an ASGI interface. Class-based views as an ASGI interface. Mountable ASGI components. An ASGI-based TestClient. Settings and configuration Per-component configuration, over global configuration settings. Implications to framework complexity Why this approach matters in terms of complexity and framework-interoperation. Challenges Does it matter enough? How to get from A to B? What does it make more difficult? What’s the bigger picture?