Django async

Getting more serious with async: using the StreamingHttpResponse

The StreamingHttpResponse is not new and allows us to stream a response, ie instead of sending it in one go you send it chunk by chunk. The use case for this in the documentation is to send a big CSV file. As the documentation points out, in WSGI, you will need a worker for the whole duration of the response. This worker won’t be able to serve any other clients. That’s where ASGI really comes handy: your worker can still server clients while it is waiting on IO. Let’s test this.

I created two new views to test this: one sync and one async. I used HTTPIE like this to view the streaming: http 'http://localhost:8000/stream' --stream (sync stream) and http 'http://localhost:8000/astream' --stream (async stream).

When using gunicorn I can serve both views. The sync one is correctly streamed. The async one responds but all in one go (ie without any streaming). And I got this warning: StreamingHttpResponse must consume asynchronous iterators in order to serve them synchronously. Use a synchronous iterator instead. It’s consistent with what the doc says:

When serving under WSGI, this should be a sync iterator. When serving under ASGI, then it should be an async iterator. […] Under WSGI the response will be iterated synchronously. Under ASGI the response will be iterated asynchronously. (This is why the iterator type must match the protocol you’re using.)

When using an ASGI server, I got the reversed behavior: the async view streamed its content while the sync one didn’t. And I got this warning: StreamingHttpResponse must consume synchronous iterators in order to serve them asynchronously. Use an asynchronous iterator instead (except for daphne which for some reason didn’t print anything).

Relevant commits:

• Test StreamingHttpResponse

Going further with async: Server Sent Events (SSE)

Instead of just stream data, how about streaming it to a browser and allowing the browser to react? This could be handy to notify the browser of some changes (like new data being inserted). Like websockets, the client could see the update immediately. Unlike Websockets, communication is unidirectional: from the server to the client. But it should be enough for many use cases and doesn’t require any extra lib.

This is done with StreamingHttpResponse and an async iterator.

How to get notified of events? You could use PostgreSQL directly thanks to its listen/notify feature or rely on the pub/sub feature of Redis.

There are several things you must pay attention to:

• Each message must be ended with two line breaks.
• The data must start with data: or you won’t be able to access the data in JS. So your payload must be like f"data: {data}".
• The content type of your response must be "text/event-stream".
• You can then create an EventSource in JS and parse each event data property.

For more details on this, please read this article.

Relevant commits:

• Test server sent events

How about Websockets?

To use Websockets, you still need to use Django Channels. It works on all servers except gunicorn (you need ASGI for this, no work around or compatibility with async_to_sync this time!).

It’s very easy to set up. To test it you don’t even need Redis (the only supported channel used to dispatch messages to all consumers) and can rely on a channel that works in memory. I only followed the official tutorial.

Relevant commits:

• Test Websocket with channel

How about HTTP2 PUSH feature?

When HTTP2 was launched I clearly remember that push was the feature everybody was exited about. I never bothered to dig and enable it, but it sounded compelling: you could push assets to the browser before it even asked for it to load them faster! This test sounded like the perfect time to give it a try.

And… it turns out Chrome removed it a couple of years ago and nginx deprecated it in June 2023 in version 1.25.1 (the directives have no effect now, but don’t yet trigger an error). Ouch!

It turns out that it’s not easy to use, makes caching a lot harder and can lead to needless resources being pushed or the same resources being pushed more than once. For more, please read this article.

I still decided to test it for the sake of it. I made it run easily with Apache. I’ll extend a bit since it not obvious:

1. I used the default httpd.conf file from the container as a basis.

2. Then I added this at the top of the file:

   Listen 80
   LoadModule http2_module modules/mod_http2.so
   Protocols h2 http/1.1
   
   LoadModule ssl_module modules/mod_ssl.so
   SSLEngine on
   Listen 443
   SSLCertificateFile "/var/certs/server.crt"
   SSLCertificateKeyFile "/var/certs/server.key"
   
   LoadModule proxy_module modules/mod_proxy.so
   LoadModule proxy_http_module modules/mod_proxy_http.so
   ProxyPass /static !
   ProxyPass "/" "http://172.17.0.1:80/"
   ProxyPassReverse "/" "http://172.17.0.1:80/"
   
   <VirtualHost *>
       DocumentRoot /var/www/html
       <Directory "/var/www/html">
           Require all granted
       </Directory>
       ServerName host
       ServerAlias *
   </VirtualHost>
   

3. I then updated my view so to would add a Link header listing the resources to push:

   response[
       "Link"
   ] = "</static/home.css>; as=style; rel=preload, </static/list.css>; as=style; rel=preload"
   

4. You can see in Firefox in the dev tools: the CSS files are loaded but not associated request is displayed in the explorer.

5. You can test it more easily with nghttp a CLI tool dedicated to testing HTTP2 connections. To do so, once you’ve installed it, you can launch it like this: nghttp -ans https://localhost:8080/async. It will list the resources loaded by the page with an asterix if they were pushed.

I never managed to make it work with hypercorn though with the same settings. Since it is being deprecated, I didn’t dig any further.

Relevant commits:

• Test with reverse proxy for benchmark & HTTP push <https://gitlab.com/Jenselme/dj-test-async/-/commit/42fa4713047291716637f3eb99709faa10b392d9>

My recommendations

After all that, what would I recommend?

• If you don’t need async and thus ASGI, you can probably stick with your current stack. It’s solid and won’t go away.
• I’d still put a reverse proxy in front of my app, even for ASGI.
• For a pure ASGI project, I think I’d use daphne and install it as an app. I’d to it because it’s the easiest to integrate with Django, including the runserver command I’m used to having during development. It also makes static files serving and template changes easier out of the box.
• uvicorn under gunicorn looks like a very good alternative. And you benefit from all the options of gunicorn in production.
• I’d reach for hypercorn only if I needed all of its features (like the ability to use uvloop or its experimental HTTP3 feature).
• If you are in the process of migration to async, I think you should start by running "old" views under WSGi and let a reverse proxy route traffic to an ASGI server for async views. Once most of your app is migrated, I think you can switch to ASGI and let is serve your sync views until you change them (or for the end of time because you’ll never have time to migrate something that works).

Having said all that, I’ll gladly hear what you think in the comments!