Hacker News Reader

Comment by dplgk | Hacker News Reader

Nice to have a simpler option than DRF which has grown into a quite complicated mound of code.

On my latest project I went with Starlette (same author DRF/core dep for FastAPI) on it's own using marshmallow for serialization.

Having written years worth of django/drf in the past, it's a breathe of fresh air with minimal dependencies, simple constructs, and good documentation. Def recommend.

starlette is amazing. Django just gets in the way.

If your needs are simple enough, built-in Django function-based views will do. When you outgrow those, DRF's complexity is often warranted.

But is DRFs complexity worth it compared to Ninja?

DRF was about as good as it got for automatic schema generation and data validation before python static type hints made things like pydantic possible. It also sets up good defaults for stuff like query parameter-based filtering, pagination, and resource relationships (it supports HATOAS by default).

I'd argue that Python type hints are actually a step back. Sure, they may work 80% of the time, but there are times where you need the extra flexibility offered by DRF serializers. Those can go way farther than the basic "map these JSON data types to this Python representation" which would then be difficult to represent using basic Pydantic-style hints (you'd have to the rest in procedural Python within your endpoint, which can't easily be reused when it comes to function-based views, where as DRF abstracts that away within the serializer which not only can be reused, but itself can be composed of multiple classes/mixins).

DRF isn't necessarily complex, you can still use its generic views.

My argument about the "complexity" of DRF is that you need to use its serializers (frankly if you're just returning raw dicts then you're already not far off from built-in, generic Django function-based views) which I guess some people may consider complex especially if the data you're representing doesn't originate from models.

> If your needs are simple enough, built-in Django function-based views will do

This is the bit I find not really true.

My needs are simple (10-20 basic get/post/put/delete APIs, many at the business logic layer than true REST) but I still would really like the OpenAPI docs, auto-generated schema definitions, etc etc. If I can get that with just some simple decorators on my existing views and pydantic models for the inputs and outputs .... that would be awesome.

That's something you can get with DRF pretty much out of the box as long as you use its routers, viewsets and serializers. DRF serializers are different than just Python type-hints, but not more complex - it's just different syntax.

I like DRF, especially when I have to come back after some time or get in a new project and looking for where things happen. But ya, boilerplate city. It really feels wrong typing out the serializers, the views, repeating the same steps over and over. It's too much.

I'm excited to try this out, been looking at FastAPI.

I like the idea of DRF, but when I only dive into it occasionally, I find it has much too much magic for my liking. "Just defined this class w/ this property and then it `just works`!" is really hard to follow if you're not familiar with it.

Reply on news.ycombinator.com