undefined | Better HN

0 pointspen2l3y ago0 comments

Why not just absorb DRF? Which as I understand is the leading choice for many, so I wonder if some effort should be dedicated to reducing fragmentation.

0 comments

3 comments · 1 top-level

simonw3y ago· 2 in thread

The problem with having things like DRF inside of Django core is that it reduces their speed of iteration.

Django releases a new version every six months. Packages that aren't part of Django core are free to release on a different schedule, which really helps when you're trying to innovate on something new.

In DRF's case it's now mature and stable enough that maybe that wouldn't be so much of a problem... but it's still not clear to me that having it in Django core would be a net benefit (aside from as a marketing thing) than having it live independently as it does today.

miiiiiike3y ago

The problem with DRF being an external package is that it does thing slightly different than Django itself would do it.

DRF’s validators don’t implement `__eq__`, Serializers doesn’t implement `serializer._meta.fields` on the base class (you have to instantiate the serializer to access anything other than `declared_fields`), lack of async view support, and on and on.

I find DRF grating and would pay anything to have an official Django REST api contrib package.

miiiiiike3y ago

Cripes. Whenever I post from my iPad I always seem to miss 2-3 autocorrect injected typos.

j / k navigate · click thread line to collapse