
Show HN: Django REST – Typed Views - rsinger87
https://github.com/rsinger86/drf-typed-views
======
rsinger87
I wanted wanted to share a package I made to enable use of type annotations
for automatic validation/sanitization in Django REST Framework.

I've borrowed ideas from the original API Star
([https://github.com/encode/apistar](https://github.com/encode/apistar))
(before it was an OpenAPI toolkit) and FastAPI
([https://fastapi.tiangolo.com/](https://fastapi.tiangolo.com/)). Instagram
engineering also had a recent blog post about how they do something similar
with Django views ([https://instagram-engineering.com/types-for-python-http-
apis...](https://instagram-engineering.com/types-for-python-http-apis-an-
instagram-story-d3c3a207fdb7)).

------
leowoo91
Looks nice! That might save 4-5 lines in beginning of the API view functions
for type checks and redundant 400 returns. Title should have "Show HN" I
think.

~~~
rsinger87
Cool, I've added the "Show HN:" prefix. Yeah, probably most useful for API
view functions, since ViewSets often handle the CRUD endpoints automatically.

------
tony
Starred.

Aside: If this is appealing to you (automated typing in REST) I think you
would love GraphQL.

Typing is baked into graphql ([https://graphql.org/learn/schema/#type-
system](https://graphql.org/learn/schema/#type-system)). You can do it with
graphene ([https://graphene-python.org/](https://graphene-python.org/)) and
django's graphene-djanago ([https://github.com/graphql-python/graphene-
django](https://github.com/graphql-python/graphene-django)) which handles ORM
wrapping and a view baseclass.

Having experience with it, one major downside is how exception handling works
in graphene. There is a strange implementation of promises which doesn't
translate well into python IMO. It ends up hijacking error resolution, making
it hard to control execution.

On the other hand, being able to get instant documentation from graphql is a
big benefit. Everything generates nicely to a schema.graphql file.

Instead of POST and PUT, graphql has a concept of mutations:
[https://graphql.org/learn/queries/](https://graphql.org/learn/queries/), GET
would be a query.

Also, graphql has built-in pagination via Connections:
[https://graphql.org/learn/pagination/](https://graphql.org/learn/pagination/)

I still use REST in many places, but graphql has been one thing where the
learning curve paid off. I wish REST had typing baked into it from the
beginning.

~~~
rsinger87
I've followed GraphQL from a distance. Besides the typing part (which it seems
like you can get from OpenAPI to some extent), the other big benefit seems to
be being able to cater to many different and unpredictable use cases. But I
haven't really had a need for that yet.

------
ptwt
Shameless self plug: a couple of days ago I posted a project that does pretty
much the same thing but built on top of flask instead of django:
[https://github.com/plainas/flask-swagger-
types](https://github.com/plainas/flask-swagger-types)

Also relying on Marshmallow but with the extra bonus of generating an openapi
spec for you and hosting swagger ui.

It puzzles me that such approach is not the norm. Interesting to see more
people tackling the same problem.

~~~
rsinger87
Very cool! Yeah, it seems like web frameworks could do more in terms of
linking up HTTP contracts with the arguments to the controller/view/whatever.
Though, sometimes you need a little more flexibility. For instance, often when
updating an existing model, the validation depends not just on the incoming
request data but also the value of the existing instance's fields.

------
OJFord
Nice. We do something similar with Django (but not DRF) + Marshmallow (+
marshmallow-dataclass (+ marshmallow-dataclass-djangofield which is a very
small module I wrote)).

