## Who am I?
## Who am I?
- My name is Rémy Hubscher — [@natim](https://twitter.com/natim)
- I am Python Backend developer since 2005
- I Worked with PeopleDoc, Mozilla, Chefclub, Alma
## What is Django?
## What is Django?
- Django is a Python web framework.
- Its development started in 2003.
- It got famous thanks to its autogenerated and configurable admin interface.
A few years ago, Andrew Godwin started to think about async Django.
- At first compatible with both Python 2 and Python 3.
- With no breaking changes on the Django side.
- With the deprecation of Python 2, the specification evolved to benefit from asyncio features.
## Django Channels
- In 2015, Andrew started to champion this and created the Channels project.
- The ASGI protocol as well as tooling around ASGI.
- The Daphne server.
- Redis Channels queue implementation.
## Disclaimer
- In 2019, the [DEP-009](https://github.com/django/deps/blob/master/accepted/0009-async.rst)
for an Async-capable Django got accepted.
- Django 3.0 started adding ASGI support.
- This talk will be focused on ASGI and Channels.
## Let me start from the beginning
## It all started with CGI
## Common Gateway Interface
- First specification written in 1973 by the National Center for Supercomputing Applications (NCSA).
- The goal is to delegate HTTP request handling to a CLI tool.
- In October 2004, the RFC 3875 specified CGI version 1.1
## Then the Python community settled on WSGI
## Web Server Gateway Interface
- WSGI was originally specified as PEP-333 in 2003.
- An implementation-agnostic interface between web servers and web applications.
- Aimed to standardize Python web frameworks.
- In 2010, PEP-3333 updates the specification for Python 3.
```python
def application(environ, start_response):
start_response(
'200 OK', [('Content-Type', 'text/plain')]
)
return 'Hello, World\n'
```
## A few years ago we started talking about ASGI
## Async Server Gateway Interface
- Wikipedia does not know about ASGI yet.
- It's the spiritual successor and a superset to WSGI.
- Provides a standard interface for async Python web servers.
```python
async def application(scope, receive, send):
event = await receive()
...
await send({"type": "websocket.send", ...})
```
## Why not keep WSGI?
## How does WSGI work?
- WSGI passes an environ with the request information.
- The Python application computes the response.
- The response is sent back and a new request can be handled.
## What's wrong with WSGI?
1. If the response takes time, other clients have to wait.
2. A worker cannot handle multiple clients at the same time.
3. To mitigate that we spawn multiple workers.
## Has anyone had to work with websocket and Python?
## Websockets
- Websockets need one connection per user.
- It doesn't fit in WSGI request/response model.
- We can't afford to have a worker per client.
## What about HTTP/2 or HTTP/3?
## HTTP/2
- A unique connection opened per user.
- A client state on the server side.
- A binary protocol that allows response for different requests to be mixed.
## HTTP/2
- You can ask for multiple files without waiting for the answer.
- You can prioritize what response are the most important to you.
- The server can push files you may need without you requesting them.
## HTTP/3
- HTTP/3 was previously called QUIC.
- It is an improvment of HTTP/2 that works on top of UDP instead of TCP.
- I encourage you to watch Daniel Stenberg's talk about HTTP/3 this afternoon. (Janson theater at 4pm.)
# To recap
- WSGI servers (uWSGI, gunicorn) are really good at hidding these restrictions.
- If the request/response model fits your needs, then WSGI is good enough.
- WSGI's synchronous response model is limiting for the asynchronous web we use today.
# The ASGI promise
## An event based protocol
- ASGI describes events instead of requests and responses.
- ASGI servers keep tabs on client connections.
- The ASGI server pushes new events to the `receive` function.
- Workers handle events and return responses through the `send` function.
- A HTTP request is just another kind of event.
## Channel architecture
## More events
- Django channels add a channel layer so that applications can communicate between them.
- You can create groups and then send and receive events to and from a group.
- You can use workers for async background tasks as well.
## An asynchronous server written in synchronous mode.
- The server is handling all the asynchronous complexity.
- Handling a task can be synchronous.
- Your workers don't have to be asynchronous.
- In Python 3, asynchronicity is not an issue anymore.
## ASGI is already popular
- ASGI is already mainstream in **Starlette** and **FastAPI**.
- Django 3 shipped an ASGI endpoint, next versions should embed more tooling.
- If you want the most of ASGI and Django, you can start today with Django Channels.
- If you find yourself using Celery, you can benefit from the
ASGI worker architecture and simplify your architecture.
## As a conclusion
- If you do backend web development in Python, you should learn more about ASGI.
- If you never heard about Starlette or FastAPI before, you should definitely try them.
- If you never tried asyncio find some time in 2020 to try it.
- Thank you for your attention
- My name is Rémy Hubscher — [@natim](https://twitter.com/natim)
- Feel free to ask me your questions.
- To learn more please visit [getalma.eu](https://www.getalma.eu/)
## How do I run my Django app with ASGI?
$ daphne myproject.asgi:application
$ uvicorn myproject.asgi:application