
Django Async: What's new and what's next? - sanketsaurav
https://deepsource.io/blog/django-async-support/
======
Bedon292
I love Django / Django Rest Framework and have used it for a long time, but we
recently dumped it from a project in favor of FastAPI.

There is just so many layers of magic in Django, that it was becoming
impossible for us to improve the performance to an acceptable level. We
isolated the problems to serialization / deserialization. Going from DB ->
Python object -> JSON response was taking far more time than anything else,
and just moving over to FastAPI has gotten us a ~5x improvement in response
time.

I am excited to see where Django async goes though. Its something I had been
looking forward to for a while now.

~~~
lmeyerov
We ended up with 2 python layers:

\-- Boring code - Business logic, CRUD, management, security, ...: django

\-- Perf: JWT services on another stack (GPU, Arrow streaming, ...)

So stuff is either Boring Code or Performance Code. Async is great b/c now
Boring Code can now simply await Performance Code :) Boring Code gets
predictability & general ecosystem, and Performance Code does wilder stuff
where we don't worry about non-perf ecosystem stuff, just perf ecosystem
oddballs. We've been systematically dropping node from our backend, where we
tried to have it all, and IMO too much lift for most teams.

~~~
VWWHFSfQ
Similarly, we ended up doing the same. Boring CRUD/CMS stuff is all in Django.
That's 90% of our codebase and by far the most important. Our "user scale"
endpoints are all implemented in Lua in NGINX and just read/write to Redis and
data changes go into SQS and processed by Celery back in the Django app. It
scales phenomenally well and we don't lose any of the great things about
developing all of our core biz-critical stuff in Django.

------
silviogutierrez
Great article. But I think this part may need as second look:

    
    
        If your views involve heavy-lifting calculations or long-running network calls to be done as part of the request path, it’s a great use case for using async views.
    

That seems true for long-running network calls (IO). But for heavy-lifting
calculations? I thought that was _the_ canonical example of situations async
won't improve. CPU bound and memory bound, after all.

~~~
ghostwriter
Perhaps they meant that heavy long-running calculations could be offloaded to
a worker pool with a help of concurrent futures and run_in_executor()

\-
[https://docs.python.org/3/library/concurrent.futures.html](https://docs.python.org/3/library/concurrent.futures.html)

\- [https://docs.python.org/3/library/asyncio-
eventloop.html#asy...](https://docs.python.org/3/library/asyncio-
eventloop.html#asyncio.loop.run_in_executor)

~~~
pdonis
This will only help if the workers are separate processes. Thread workers will
hold the GIL in Python and prevent network I/O while they are doing CPU bound
tasks.

~~~
dr_zoidberg
> Thread workers will hold the GIL in Python and prevent network I/O while
> they are doing CPU bound tasks.

Using cython:

    
    
        with nogil:
            # whatever you need to do, as long as it
            # doesn't touch a python object
    

If you're doing heavy calculations from python you should at least be
considering cython.

------
abledon
Whats the most elegant way for cutting edge Django to do websockets? is it
still to 'tack' on the channels package [0] ?

compared to FastAPI[1] I really don't want to use it, I only miss the ORM
since in FastAPI it looks like you have to manually write the code to insert
stuff[2].

[0] [https://realpython.com/getting-started-with-django-
channels/](https://realpython.com/getting-started-with-django-channels/)

[1] [https://fastapi.tiangolo.com/advanced/websockets/#create-
a-w...](https://fastapi.tiangolo.com/advanced/websockets/#create-a-websocket)

[2] [https://fastapi.tiangolo.com/tutorial/sql-
databases/#create-...](https://fastapi.tiangolo.com/tutorial/sql-
databases/#create-data)

~~~
scrollaway
As someone who's done over a decade of Django work: Do use FastAPI,
_especially_ if you need websockets and such.

Django is great for CRUD apps, MVPs and such. And I've used it with success
for larger platforms, but it doesn't take long for me to want something closer
to the metal whenever I need custom work. FastAPI has filled that need
wonderfully well.

I also miss the ORM though… SQLAlchemy is a pain.

------
hyuuu
time and time again, whenever I start a new project, Django has always been my
go-to choice after analyzing the alternatives. I've worked on large scale,
mono-repo, billion users to side projects over the weekend, Django really stay
true to the batteries included philosphy.

------
leafboi
Wasn't there an article about how the async syntax was benchmarked to actually
be _slower_ than the traditional way of using threads? What's the current
story on python async?

reference: [http://calpaterson.com/async-python-is-not-
faster.html](http://calpaterson.com/async-python-is-not-faster.html)

~~~
tomnipotent
The built-in event loop has meh performance, would love to see the benchmarks
re-run using libuv - that would help close some of the gap.

~~~
leafboi
They max out the speed with tests. It does use libuv. Uvicorn is the indicator
as it uses libuv underneath.

If you heard of Gunicorn, Uvicorn is the version of Gunicorn with libUV, hence
the name.

------
dec0dedab0de
I think the article and some of the comments are not really looking at this
the right way.

For most things you're probably better off "doing the work" in a celery task,
regardless if it is IO bound or CPU bound. Then use web sockets just for your
status updates/progress bar, instead of having your front end poll on a timer.

~~~
emptysea
The downside of using web sockets is they complicate deployment and reliable
delivery is more difficult than `/status?since=$pk`

------
honkycat
I love django, have not used it in years though. I've been in JavaScript land.

I'm consistently surprised that there are not awesome web frameworks in
JavaScript similar to Django

~~~
anaganisk
I recently stumbled upon keystone and Strapi, they seem a potential contender

~~~
midrus
I'm also coming from Django. I've found Keystone to fit my brain a lot better
than most alternatives. Tried strapi and it looks good for basic stuff but the
documentation is just absolutely terrible, and once you get out of the really
basic stuff you're on your own digging into their source code to understand
how to do anything. Nonetheless, ok it looks promising and maybe in a few
years it could be something more interesting (to me at least).

~~~
midrus
Oh, and by the way, the reason I'm not using keystone either is because it
doesn't support sqlite (for real).

------
djstein
I’ve seen lots of blog posts, even the Django docs, saying async is available
but still haven’t seen any real world examples yet. Do any exist?

Also, I still haven’t seen how the async addition will work with Class Based
Views. Also, Django Rest Framework is still considering spending time for
support. Until these two use cases are viable many users won’t benefit.

------
kissgyorgy
> If your views involve heavy-lifting calculations ...

Nooo, not at all. Your tasks should be I/O bound, not CPU bound to take
advantage of asyncio. Maybe the async server using multiple threads with
multiple event loops, but don't ever do a CPU-heavy task in an event loop
because you just invalidated using asyncio completely.

------
IgorPartola
Looking at the async view example, at what point can we just drop async/await
keywords and just have Python assume that everything is asynchronous?

~~~
anaganisk
javaScript ecosystem went out of the way to bring async await keywords,
despite Node.js being asynchronous by using call backs and promises. The
argument being code readability, While async await are just wrappers around
Promise system.

------
ArtDev
I had a bad experience with Django. I found it cluttered and slow. I really
wanted to like it. It might seem funny but a more straightforward framework
like Symfony didn't get it in the way and ended up much faster. Python should
be much much faster than PHP but I guess the framework matters a lot too.

~~~
IceWreck
> Python should be much much faster than PHP

How? Afaik PHP is faster than Python in most aspects.

