Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: