Django 4.1
djangoproject.com
Django 4.1
1–10 of 126 posts
Re: Django 4.1
#2I wonder how popular the async interface will become. I use Python and Django extensively but haven't touch any of the async operations.
Re: Django 4.1
#3I wonder how popular the async interface will become. I use Python and Django extensively but haven't touch any of the async operations.
Once the underlying database queries become async, I can see it becoming popular. Many views do multiple database queries that aren't dependent on each other, which would be a quick win to make async.
Re: Django 4.1
#4I wonder how popular the async interface will become. I use Python and Django extensively but haven't touch any of the async operations.
Since ultimately anything you build in Django will eventually go into the ORM layer, it won't become anything unless the ORM is fully async. This release brings the async API to it, but:
> Note that, at this stage, the underlying database operations remain synchronous
That kinda defeats the whole purpose of an ASGI app.
Re: Django 4.1
#5The most anticipated Django release for me personally. Async ORM access is a massive quality of life improvememt, same for async CBV. The later is also a blocker for Django Rest Framework going async.
Sure most CRUD applications work perfectly fine using WSGI, but for anyone using other protocols like WS or MQTT in their app this is kind of a big deal.
Re: Django 4.1
#6The most anticipated Django release for me personally. Async ORM access is a massive quality of life improvememt, same for async CBV. The later is also a blocker for Django Rest Framework going async. Sure most CRUD applications work perfectly fine using WSGI, but for anyone using other protocols like WS or MQTT in their app this is kind of a big deal.
Also, async views allow for better scaling. Say your view needs to make an API call to a third party service within a request-response cycle. Currently, this will block an entire worker/thread while doing a blocking request.
With async, we can use async HTTP libraries and scale these WAY better.
Re: Django 4.1
#7The most anticipated Django release for me personally. Async ORM access is a massive quality of life improvememt, same for async CBV. The later is also a blocker for Django Rest Framework going async. Sure most CRUD applications work perfectly fine using WSGI, but for anyone using other protocols like WS or MQTT in their app this is kind of a big deal.
Also, async views allow for better scaling. Say your view needs to make an API call to a third party service within a request-response cycle. Currently, this will block an entire worker/thread while doing a blocking request. With async, we can use async HTTP libraries and scale these WAY better.
Or just run 20 workers and let the OS handle async. OSes are pretty good at this. Async is pretty hard to reason about.
Async is beneficial when you make multiple blocking (http) request to a resource at the same time and later fold that into one response. Parallel stuff. Or when you are forced to run a single thread. Or when you are memory bound.
Reality is that most requests depend on previous requests quite often. In the latter case there is no benefit in terms of speed for the user.
I know this is unpopular opinion though :-)
Re: Django 4.1
#8If anyone is interested I updated my example Django Docker app to 4.1 at: https://github.com/nickjj/docker-django-example
It includes running Django, Celery, gunicorn, Postgres, Redis, esbuild and Tailwind through Docker and Docker Compose. It's set up for development and production.
Re: Django 4.1
#9Earlier quoted context omitted.
Also, async views allow for better scaling. Say your view needs to make an API call to a third party service within a request-response cycle. Currently, this will block an entire worker/thread while doing a blocking request. With async, we can use async HTTP libraries and scale these WAY better.
Or just run 20 workers and let the OS handle async. OSes are pretty good at this. Async is pretty hard to reason about. Async is beneficial when you make multiple blocking (http) request to a resource at the same time and later fold that into one response. Parallel stuff. Or when you are forced to run a single thread. Or when you are memory bound. Reality is that most requests depend on previous requests quite often.…
Might be unpopular but still good to stick to it. I tend to associate excessive enthusiasm for pythons async await framework as a sign of immaturity and potential for doing things without understanding them fully. I’d never trust async code from anyone except the best python engineers. Most of them out there can’t even debug linear code, adding async to the mix only makes it worse. At least you can trust the time stamps.
Re: Django 4.1
#10The most anticipated Django release for me personally. Async ORM access is a massive quality of life improvememt, same for async CBV. The later is also a blocker for Django Rest Framework going async. Sure most CRUD applications work perfectly fine using WSGI, but for anyone using other protocols like WS or MQTT in their app this is kind of a big deal.
## Asynchronous ORM interface
https://docs.djangoproject.com/en/4.1/releases/4.1/#asynchro... :
`QuerySet` now provides an asynchronous interface for all data access operations. These are named as-per the existing synchronous operations but with an `a` prefix, for example `acreate()`, `aget()`, and so on.
> The new interface allows you to write asynchronous code without needing to wrap ORM operations in `sync_to_async()`:
async for author in Author.objects.filter(name__startswith="A"):
book = await author.books.afirst()
## Asynchronous handlers for class-based views
> View subclasses may now define async HTTP method handlers:
import asyncio
from django.http import HttpResponse
from django.views import View
class AsyncView(View):
async def get(self, request, *args, **kwargs):
# Perform view logic using await.
await asyncio.sleep(1)
return HttpResponse("Hello async world!")