4 ms·
Show HN: Django REST – Typed Views
- rsinger87 7y agoI 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-an-instagram-story-d3c3a207fdb7 https://instagram-engineering.com/types-for-python-http-apis...).
- leowoo91 7y agoLooks 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 7y agoCool, I've added the "Show HN:" prefix. Yeah, probably most useful for API view functions, since ViewSets often handle the CRUD endpoints automatically.
- OJFord 7y agoNice. We do something similar with Django (but not DRF) + Marshmallow (+ marshmallow-dataclass (+ marshmallow-dataclass-djangofield which is a very small module I wrote)).
- tony 7y agoStarred. 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 7y agoI'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 7y agoShameless 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 7y agoVery 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.