5 ms·
Can you explain from a high level why I’d want to use Django Ninja over DRF? There’s a vibe, or assumption around Ninja that it’s “newer”, or “like FastAPI”, o
by halfcat 3y ago
Can you explain from a high level why I’d want to use Django Ninja over DRF?
There’s a vibe, or assumption around Ninja that it’s “newer”, or “like FastAPI”, or “the way forward”, none of which are objective benefits per se.
I wouldn’t even say I’m an advanced DRF user, but with a handful of small functions to create ModelSerializer subclasses and ModelViewSet subclasses, I have basically auto-CRUD for any Django model in DRF, and Ninja always seemed verbose by comparison.
Maybe I just have really simple use cases that work with this approach. Like, are there examples you can share that would be painful in DRF that are easier to navigate in Ninja? Or is it just personal preference of liking the more freeform style of FastAPI?
- bb88 3y agoI think the big issue is that everyone like pydantic and are willing to put it in places it may not really see a big benefit, over say, DRF. OTOH, if you're a big fan of NoSQL databases, then pydantic is a godsend.
- mejutoco 3y agoDRF is very dynamic. While useful, it does too much magic for my taste. Pydantic pure data models, combined with typeguard annotations do it for me. Plain functions with defined input output types. It helps validate all the assumptions and catch errors earlier.
- Loeffelmann 3y agoIt will never stop being funny to me when NoSQL people need schemas for their schemaless database.
- physicsguy 3y agoThey have a schema, they just don’t want to write it down. So they write it down in code instead of course. Which isn’t fragile at all…!
- patmorgan23 3y agoIt's almost as if schemas and static types were a good idea/expression of a fundamental reality.
- WD-42 3y agoAs mentioned elsewhere in this thread, simple CRUD usually stops being simple CRUD pretty quickly. If you are actually doing simple CRUD, then DRF's ModelViewSets are great, and Pydantic would indeed be an overkill. However once the view diverges from your DB model, writing Pydantic models IMO is FAR superior than having to write custom DRF serializers.
- bb88 3y agoThe key there is 'IMO' isn't it? If the DB is your schema, great, DRF is awesome. But if the DB is not your schema, no problem, DRF still can handle it. And with DRF you get CRUD by default. And if you don't want CRUD, no problem, DRF has generic API views too.
- WD-42 3y agoSo exactly like this package and ninja? Except instead of writing un typed drf serializers you get to write small, concise pydantic models.
- kolanos 3y agoNinja supports async, DRF is still synch only?
- WD-42 3y agoIt's a much nicer development experience because of typing and pydantic. If you are using a language server, it's a game changer. Ninja also has async view support, I'm not sure the status of DRF in this regard. The auto generated docs are much nicer (swagger). It's MUCH more lightweight than DRF. Unless you are using OP's package, there are no giant class based view hierarchies and viewsets and all that, just plain functions for views. In which you define the input and output as pydantic schemas, it's so simple and refreshing.
- seabrookmx 3y agoDRF falls apart very quickly when you get away from the "simple CRUD" use cases. The Serializer mechanism causes N+1 query behavior by default with non-trivial models. This is exacerbated by the fact that they all run in sequence because there's no async support. It's documentation is also pretty poor, IMO. > There’s a vibe, or assumption around Ninja that it’s “newer”, or “like FastAPI”, or “the way forward”, none of which are objective benefits per se. The creator of DRF also created starlette, which underpins FastAPI. If DRF works for you cool, but that doesn't mean the community hasn't moved on.
- oflannabhra 3y agoThis is my expo with DRF exactly. If you want to serve ORM models over REST, it’s amazing and fast. If you have complex business logic it becomes a nightmare.