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

91–100 of 126 posts

Re: Django 4.1

#91

Post by Evidlo »

giancarlostoro wrote: post #27
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.

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…

PonyORM is sort of like Django's

Re: Django 4.1

#92

Post by roflyear »

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. Async in Python is... eh. Rarely is it useful. Sometimes it is, though! Use it when it is useful...

Re: Django 4.1

#93

Post by roflyear »

ralmidani wrote: post #40
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.

Enabling async means those already invested in Django can do more on one machine without a complete rewrite, and those considering it can adopt it with fewer reservations. There will always be more scalable platforms out there, but enabling async with Django helps it serve the “sweet spot” in terms of both ergonomics and scalability.

Probably not. If you need async for DB "stuff" to take advantage of your resources, I think it is a rare thing, and likely you would not want to use the ORM anyway, and then can just do whatever you want without it.

Re: Django 4.1

#95

Post by godtoldmetodoit »

BiteCode_dev wrote: post #63

This is going to make django-ninja even easier to use, so it's very welcome. And if you like django and never tried django ninja, it's like DRF and FastAPI had a baby: https://django-ninja.rest-framework.com/ . You define your endpoints using pydantic type hints, and it generates the API, validators and docs all in one go.

+1 on Ninja. Been using it on a number of projects the last 6 months, and its been a joy to use.

Re: Django 4.1

#96

Post by theptip »

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 really shines if you are doing simple CRUD APIs where you can lean on autogenerated routes, views, and serializers. Since you can get full CRUD for a model in something like 10 lines of code.

When you need to wire up custom serializers per model (eg specifying subsets of fields or making some read-only) and wire up non-CRUD actions then I think you can fall down a slippery slope where you write as much (or more) code than if you just used say marshmallow and flask to manually write your API.

Also you get the Django model admin for free, so for internal services you have a nice CRUD admin for operators.

I think it’s a great tool for accelerating your first 100-200kloc of API code. Beyond that it can start to creak at the seams depending on your usecase. (I’d make the same assessment about Django itself FWIW).

Re: Django 4.1

#97

Post by tmpz22 »

baq wrote: post #88
zzzeek wrote: post #70

looking at the release notes and the source, it looks like the asyncio interface is still using the old drivers, like psycopg2 for postgresql, and using a threadpool. we at SQLAlchemy came up with a way to interface asyncio frontend and backend (like asyncpg for the driver) while maintaining all the "in the middle" code as synchronous style. the dark secret is that for this approach you have to use greenlet to propag…

thanks for sqlalchemy. it's a shining star in the Python package ecosystem. > interface asyncio frontend and backend (like asyncpg for the driver) while maintaining all the "in the middle" code as synchronous style. the dark secret is that for this approach you have to use greenlet to propagate the "await" operations. It's been in our release for 18 months now with 1M downloads a day and there have been no problems r…

Is it a shining star or a rough dirty pragmatic get-the-job-done tool with a heart of gold thats approachable to newcomers and grizzled veterans alike. The trenches are too dirty for shining stars.

Re: Django 4.1

#99

Post by snapcaster »

zzzeek wrote: post #70

looking at the release notes and the source, it looks like the asyncio interface is still using the old drivers, like psycopg2 for postgresql, and using a threadpool. we at SQLAlchemy came up with a way to interface asyncio frontend and backend (like asyncpg for the driver) while maintaining all the "in the middle" code as synchronous style. the dark secret is that for this approach you have to use greenlet to propag…

Just want to say thanks for SQLAlchemy work! Love the package and use it in every one of my work and personal projects

Re: Django 4.1

#100

Post by syastrov »

There are a lot of comments about async ORM, but to me the support for application-level (e.g. if you use forms, admin, DRF, Graphene) validation of DB-level constraints is a super cool feature that solves a real pain point - having to duplicate this logic at both levels, or forgetting to do so.
Post reply on HN