11–20 of 126 posts
If 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.
Earlier 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.…
def slow_sync_view(request):
# these requests won't be executed in parallel;
# async version could eliminate this extra latency
foo = requests.get('https://www.google.com/humans.txt').text
bar = requests.get('https://checkip.amazonaws.com').text
return HttpResponse(f'{foo}\n{bar}')If 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.
Guess I best upgrade my production side-project from Django 1.5.9
If 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.
That seems to be using WSGI, not ASGI, though, so no natively `async` views..?
One does not simply go async. Changing your entire app to go full async has serious implications, requires every library you use to support it and requires a completely different mode of thinking.
The example project includes an ASGI file if you want to use an async app server like uvicorn with async views instead of gunicorn. That would involve changing a couple of lines of code. That's very much a "per user" decision and in my opinion shouldn't be the default for the project when 4.1 only landed a few hours ago. It's going to take a long time until apps are ready to go async by default, both from waiting on libraries to support it and the community to shift towards this style of building apps.
I 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.
Earlier quoted context omitted.
That seems to be using WSGI, not ASGI, though, so no natively `async` views..?
> That seems to be using WSGI, not ASGI, though, so no natively `async` views..? One does not simply go async. Changing your entire app to go full async has serious implications, requires every library you use to support it and requires a completely different mode of thinking. The example project includes an ASGI file if you want to use an async app server like uvicorn with async views instead of gunicorn. That would…
Also, "4.1 only landed a few hours ago" isn't the perfect argument in my books since support for ASGI and async views in general was added back in 3.0 and 3.1:
* https://docs.djangoproject.com/en/4.0/releases/3.0/#asgi-sup... * https://docs.djangoproject.com/en/4.0/releases/3.1/#asynchro...
Earlier quoted context omitted.
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 sta…
Other than that, it has benefits too! :-)
The 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.