41–50 of 126 posts
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.
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.
In a way, yes.
Async in django means that with relatively minor adjustments to your codebase you may significantly increase your requests over time throughput.
And as someone else pointed out, if you have database queries that do not depend on each other you can effectively wait for their results in parallel, which might this time not only increase throughput but also lower the total request time.
It’s a very valuable development that brings significant gain for relatively minor changes.
If you are a professional django developer you should not dismiss such developments like that.
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.
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 you are writing view code in DRF, you are probably doing it wrong.
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.
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.
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…
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 import and use the advanced features if you want/need to.
Earlier quoted context omitted.
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.
But you could use it for load not tied to database, isn't it? Like CPU, IO or network bound stuff...
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.
## 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…
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?