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

51–60 of 126 posts

Re: Django 4.1

#51

Post by Demiurge »

game_the0ry wrote: post #34

Am I bad SWE if I do not care for for async in django? I am sure a a lot of django devs will like it, but if I need the performance that I would get from going async, I would not being using django as my web framework. FWIW I like django / python for a lot of things, just not for performance.

No, I agree with you. It's 2022 and I have thought only once that it would be neat to have async methods from Django, but only as some 'cool thing to try'.

I don't actually actually know if there would be any substantial benefit. It's like when I tried PyPy as my django interpreter. It gave a few percent speed increase in "real world" but created extra work for deployment.

I've been using Django non-stop from 0.96, and it just works, and you can build around it. If I was running a trading clearing house, or Instagram, I'd probably care about marginal improvements, and then use another language. But for Django, just tuning the workers per server node, and using django-rq jobs works really well.

Kudos for the enthusiasts working on this though, because 'async' is a new Python feature/meme, and supporting it is just being a good ecosystem player.

Re: Django 4.1

#52

Post by megaman821 »

aynyc wrote: post #48
westurner wrote: post #10

Earlier quoted context omitted.

## 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_asyn…

I don't fully understand the sync_to_async() operation here. So the underlying database is not async, then is Django just tossing the sync DB call onto a thread or something?

Yes, it is just being put on a thread. A future Django release will use async database drivers. Django is very incrementally adding support for async. I don't believe they have started work on async templates yet, which will be one of the last major areas before the framework is fully async.

Re: Django 4.1

#53

Post by omarhaneef »

nickjj wrote: post #8

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.

I was going to say you should offer a tutorial around how this can be used. It is much more useful to have a walk through when people put out such products.

And then I decided not to say that because it is up to you how to spend your time and why should you make a tutorial for people if you don't want to.

And then I realized, you have actually made dozens and this is the work you do. I think I took a Flask-docker course of yours on Udemy a few years ago. It was pretty good, and "forward leaning" for the time.

I know you're not allowed to shill your product on here, but presumably I can.

Re: Django 4.1

#54

Post by ElectricalUnion »

JimDabell wrote: post #31
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. That just means you can only handle 20 concurrent requests before performance drops off a cliff. If the third-party service you are talking to is slow, then you’ll just end up with 20 workers all waiting for the service to respond, while other requests pile up. With async, those workers could still be handling other requests. Adding more workers because you are bl…

> Adding more workers because you are blocking on i/o works for low traffic services, not for anything remotely busy.

Yes.

That just means in very bad cases, you can only handle 1 "concurrent request" before performance drops off a cliff. If the third-party service you are talking to is that slow, then you’ll just end up with bufferbloat (high latency in hidden queues) waiting for the service to respond, requests piling up.

With async, unless you know what you're doing and handle back pressure, work pile up even worse, the service stops working and you get 0 throughput instead.

Re: Django 4.1

#55

Post by danmur »

chpmrc wrote: post #29
tgv wrote: post #20

Earlier quoted context omitted.

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.

I just make normal money and I don't want to have lunch with Jeff Bezos. Maybe in this scenario you lose money each time you hear it and you're so in debt that Jeff Bezos has basically purchased you :P.

Re: Django 4.1

#56

Post by ralmidani »

Django is single-handedly responsible for making me fall in love with programming. I am now using Elixir/Phoenix and 100% sold on the benefits of working with immutable data, but I still keep an eye on developments in the Python/Django ecosystem. Seeing Django edge closer to having a fully async stack is very exciting, and should make it a more viable platform for existing users as well as newcomers.

Re: Django 4.1

#57

Post by ingenieroariel »

znpy wrote: post #46
giancarlostoro wrote: post #27

Earlier quoted context omitted.

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

I remember watching a beautiful talk from some pycon whose details I can’t remember about using django as if it was a micro-framework. It basically boils down to rejecting the folder structure that django-admin sets up for you, importing stuff yourself and doing some basic initialisation/configuration. Once you do that, django kinda somehow behaves like a micro-framework, with the significant difference that you can…

Here is an example of a single file Django project I started around eight years ago that does what you mention:

https://github.com/planetfederal/registry/blob/149a2b958dd05...

Re: Django 4.1

#58

Post by collinmanderson »

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.

Why do a REST-like service?

It makes sense as backend for a native iOS/Android app, and if you already have that REST endpoint then it can make sense to re-use it for the web-version of your app.

But if you're not doing an iOS/Android app (most websites?), then I generally agree it's a lot more work compared to form-based / server-side-templates (though sometimes can give a _slightly_ better user experience, _if_ done correctly.)

HTMX seems to be growing as a "REST endpoint" alternative, but again not as useful if you're also doing a native iOS/Android app.

Re: Django 4.1

#59

Post by collinmanderson »

megaman821 wrote: post #52
aynyc wrote: post #48

Earlier quoted context omitted.

I don't fully understand the sync_to_async() operation here. So the underlying database is not async, then is Django just tossing the sync DB call onto a thread or something?

Yes, it is just being put on a thread. A future Django release will use async database drivers. Django is very incrementally adding support for async. I don't believe they have started work on async templates yet, which will be one of the last major areas before the framework is fully async.

Yes, they're working from the top of the stack down, so first it was views+middleware, now it's the top layer of the database stack, and in future releases they'll work on pushing native async lower and lower in the stack.

Basically every function call that does db-queries needs an "a"-prefixed version. aget(), acreate(), aget_or_create(), acount(), aexists(), aiterator(), __aiter__, etc. And in future versions they'll work on the lower level, undocumented api, like _afetch_all(), aprefetch_related_objects(), compiler.aexecute_sql(), etc.

Eventually you'll probably need to switch database drivers to something that actually supports async.

Re: Django 4.1

#60

Post by metadat »

chpmrc wrote: post #29
tgv wrote: post #20

Earlier quoted context omitted.

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.

Gross, why would you want this? Improve your standards matey. What a sad thing to aspire to.
Post reply on HN