Hacker News Reader

Comment by halfcat | Hacker News Reader

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?

View on HN

DRF 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.

This 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.

It'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.

I 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.

It will never stop being funny to me when NoSQL people need schemas for their schemaless database.

It's almost as if schemas and static types were a good idea/expression of a fundamental reality.

They 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…!

As 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.

The 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.

So exactly like this package and ninja? Except instead of writing un typed drf serializers you get to write small, concise pydantic models.

DRF 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.

Ninja supports async, DRF is still synch only?

Reply on news.ycombinator.com