Show HN: Django REST – Typed Views
github.com
Show HN: Django REST – Typed Views
1–9 of 9 posts
Re: Show HN: Django REST – Typed Views
#2I 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) (before it was an OpenAPI toolkit) and FastAPI (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...).
Re: Show HN: Django REST – Typed Views
#3Looks 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.
Re: Show HN: Django REST – Typed Views
#4Looks 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.
Cool, I've added the "Show HN:" prefix. Yeah, probably most useful for API view functions, since ViewSets often handle the CRUD endpoints automatically.
Re: Show HN: Django REST – Typed Views
#5Nice. We do something similar with Django (but not DRF) + Marshmallow (+ marshmallow-dataclass (+ marshmallow-dataclass-djangofield which is a very small module I wrote)).
Re: Show HN: Django REST – Typed Views
#6Starred.
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). You can do it with graphene (https://graphene-python.org/) and django's graphene-djanago (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/, GET would be a query.
Also, graphql has built-in pagination via Connections: 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.
Re: Show HN: Django REST – Typed Views
#7Starred. 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 ). You can do it with graphene ( https://graphene-python.org/ ) and django's graphene-djanago ( https://github.com/graphql-python/graphene-django ) which handles ORM wrapping and a view baseclass. Having experience with it, one major downsi…
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.
Re: Show HN: Django REST – Typed Views
#8Shameless 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
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.
Re: Show HN: Django REST – Typed Views
#9Shameless 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 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.
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.