4 ms·
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.
by pen2l 4y ago
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.
- deleted 4y ago[deleted]
- simonw 4y agoThe 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.
- miiiiiike 4y agoThe 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.
- miiiiiike 3y agoCripes. Whenever I post from my iPad I always seem to miss 2-3 autocorrect injected typos.