Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Django 4.1

djangoproject.com

Post reply on HN
Print view View original

21–30 of 126 posts

Re: Django 4.1

#21

Post by varispeed »

tgv wrote: post #20
WhatsName wrote: post #5

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.

Seriously: why use Django for a REST-like service? I inherited an application that (probably) evolved from form-based to REST with a JS frontend, and I fail to see the point. There's a model, a serializer, handlers to implement relations, and multiple views per data type . It's so much overhead, and everything has to be kept in sync.

It all depends how it is written. While Django and REST is quite strongly opinionated, you can still make it difficult to maintain if you want to. That being said, Django REST allows you to move fast. It's very very easy to knock out a REST API and data models plus some basic admin panel. Once your API matures - you can then reimplement it in Go or other platform.

Re: Django 4.1

#22

Post by pdhborges »

maxmalysh wrote: post #12
BozeWolf wrote: post #7

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

> Or just run 20 workers and let the OS handle async. OSes are pretty good at this. Async is pretty hard to reason about. 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}')

I think you are being down voted because a straight port of this code to async would still run one request after the other.

You would have to queue one task for each request in the event loop and then await for them both to gain some parallelism in the I/O section of the code.

Re: Django 4.1

#23

Post by syrusakbary »

WhatsName wrote: post #5

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.

I completely agree. I have been using GraphQL in Django with WebSockets and ASGI and it was a bit of pain in the ass to get everything working, but with this changes things will get much smoother.

Great work Django team!

Re: Django 4.1

#24

Post by mrmikardo »

BozeWolf wrote: post #19
ramraj07 wrote: post #9

Earlier quoted context omitted.

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…

Or when accidentally some blocking database driver is used, even when django's ORM is async, a query with mongodb's driver is not async. Or just the filesystem... This harms performance badly, especially if the idea was to run only a few threads. Other than that, it has benefits too! :-)

And indeed, there's an important caveat in the Django 4.1 docs;

Note that, at this stage, the underlying database operations remain synchronous, with contributions ongoing to push asynchronous support down into the SQL compiler, and integrate asynchronous database drivers....

https://docs.djangoproject.com/en/4.1/releases/4.1/#asynchro...

Re: Django 4.1

#25

Post by bpicolo »

BozeWolf wrote: post #7
WhyNotHugo wrote: post #6

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

Java's Loom model really does feel like the future of concurrency in many ways.

Re: Django 4.1

#26

Post by VWWHFSfQ »

nickjj wrote: post #16
akx wrote: post #13

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…

> use an async app server like uvicorn with async views instead of gunicorn

I believe gunicorn with the uvicorn worker class is the recommended production server.

> For production deployments we recommend using gunicorn with the uvicorn worker class.

https://www.uvicorn.org/#running-with-gunicorn

Re: Django 4.1

#27

Post by giancarlostoro »

tgv wrote: post #20
WhatsName wrote: post #5

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.

Seriously: why use Django for a REST-like service? I inherited an application that (probably) evolved from form-based to REST with a JS frontend, and I fail to see the point. There's a model, a serializer, handlers to implement relations, and multiple views per data type . It's so much overhead, and everything has to be kept in sync.

I went with Django Rest Framework when I used it for a project because it provided things I would otherwise spend says implementing out of the box. The one thing I definitely did implement for myself was filtering, the built-in stuff was kind of mediocre for our needs, outside of that I want to say we left pagination and everything else as-is. It was a bit of a nightmare to look up documentation on though I will admit, if you don't know the Google Buzzword Soup you got to look up. Previously to that I was using CherryPy and building my entire kitchen sink myself, so it had nice moments and bad moments, but it definitely saved me on time and effort.

You typically do Django + REST because you are already comfortable with Django or because you were already using it, although I could argue, you could consider making your API project stand alone and using CherryPy or even FastAPI for a much nicer experience. The downside there being you wouldn't be using Django's ORM. I really do wish Django's ORM would be spun off into a stand alone project that Django then imports, so anyone else can use it in other non-django specific projects.

Re: Django 4.1

#28

Post by KptMarchewa »

maxmalysh wrote: post #12
BozeWolf wrote: post #7

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

> Or just run 20 workers and let the OS handle async. OSes are pretty good at this. Async is pretty hard to reason about. 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}')

Basic concurrent.futures.ThreadPoolExecutor solves this problem.

https://docs.python.org/3/library/concurrent.futures.html#co...

Re: Django 4.1

#29

Post by chpmrc »

tgv wrote: post #20
WhatsName wrote: post #5

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.

Seriously: why use Django for a REST-like service? I inherited an application that (probably) evolved from form-based to REST with a JS frontend, and I fail to see the point. There's a model, a serializer, handlers to implement relations, and multiple views per data type . It's so much overhead, and everything has to be kept in sync.

If I had a dollar for every time I heard this I would be having lunch with Jeff Bezos right now.

Re: Django 4.1

#30

Post by chpmrc »

BozeWolf wrote: post #7
WhyNotHugo wrote: post #6

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

Why would you block a process that could use CPU cycles to do something useful just to wait on I/O? With the right primitives async is not "hard" nor inconvenient. Maybe you're referring to concurrency?
Post reply on HN