articles/2025/async-django-why/

[giscus[bot]]

articles/2025/async-django-why/

While a technical marvel, async Django has been quietly rejected by the community it was built for, with the vast majority of developers sticking to simpler, proven solutions.

https://www.loopwerk.io/articles/2025/async-django-why/

[gulagkulak]

I had a high-concurrency slow API use case on a recent project, implemented it with async, and found out that Django's async literally does not work, because it cannot handle TCP backpressure.

Suppose you need to read a really large file chunk-by-chunk from an upstream AI, you need to do something to each chunk, and then send the chunks to a client. When you do that with standard async Django using its built-in Daphne server, you end up using all the memory and dropping most of the packets, because Daphne does not stop you from writing a new chunk when the client hasn't finished consuming the previous chunk.

Luckily there's Hypercorn, which is pretty much a drop-in replacement for Daphne and handles TCP backpressure like a champ, so you actually get the scaling benefits of async Django if you really need them for your particular use case.

[timrichardson]

I've been using a stand alone websocket server for a few years while I experimented with channels, in the end I just modernised the standalone python websocket server.. However, I do have some API endpoints that would probably benefit from async management, and I swapped my webserver run uvicorn workers which caused no problems at all, even if I am not serving any async stuff yet