Async and Django don't mix well and I honestly see the whole Django Async as wasted resources, all those "a" prefixed functions etc.
To be honest, I never liked the way async is done in python at all.
However, I love Django and Python in general. When I need "async" in a http cycle flow, I use celery and run it in background.
If client side needs to be updated about the state of the background task, the best is to send the data to a websocket channel known to the client side. Either it's Chat response with LLM or importing a huge CSV file.
Simple rule for me is, "don't waste HTTP time, process quick and return quick".
> If client side needs to be updated about the state of the background task, the best is to send the data to a websocket channel known to the client side.
SSE is nice.
Right up until your user opens your site in more than 6 tabs.
And then you need http2.
(especially the Mercure protocol which makes stuff so simple)
There’s also Django channels which is pretty sweet for certain tasks, especially websockets.
I use a combination or channels and celery for a few projects and it’s works great.
The problem with channels is that if you need to touch the ORM you will have to use a sync_to_async call which will block the event loop.
+1
but I still hope at some point they will manage to fix the devx with django/python and async
Django should just not be used period. Fast API + Uvicorn is all you need these days. It does the async for you.
With LLMS, you shit out working production ready web apps in 2 days now that are quite performant, as long as you don't care about code maintainability long term.
FastAPI+Unicorn is good but it is barebones compared to what django already has. I can see why someone with experience in latter would not choose a new stack.
Also performance wise FastAPI + uvicorn have many pitfalls as well, most of them being of asyncio.