[Alir3z4]

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".

[robertlagrant]

> 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.

[revicon]

Right up until your user opens your site in more than 6 tabs.

[robertlagrant]

And then you need http2.

[Oxodao]

(especially the Mercure protocol which makes stuff so simple)

[bodhi_mind]

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.

[pdhborges]

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.

[vb-8448]

+1

but I still hope at some point they will manage to fix the devx with django/python and async

[ActorNightly]

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.

[never_inline]

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.