(One of my summaries of a talk at the 2019 PyGrunn conference).
GraphQL is a different way to create APIs. So: differently from REST. You describe what you want to recieve back, instead of having a fixed REST api. With REST you often get too much or too little. You may need to do a lot of different calls.
REST often leads to a tight coupling between the front-end and the back-end. Changes to a REST api often break the front-end...
What they especially like about GraphQL: it is designed to have documentation build-in.
What they use: "graphene", "graphene-django" and "relay". On the front-end it is "apollo" (react-native, react, native ios/android).
With graphene-django you first have to define the data you're exposing. The various object types the types of the attributes, the relations, etc.
A tip: differentiate between "a user" and "me". Don't add more data to a user object if it turns out to be you. Just have a separate endpoint for "me". Way easier.
Caching: that needs to be done outside of graphene, it only can do a bit of caching right at then end on the resulting json. You're better off caching at the django object level.
A potential problem spot is the flexibility that GraphQL gives you in querying relations. You need to do quite some clever hacking to use django's select_related/prefetch_related speedups. You need to pay attention.
Uploading files is tricky. GraphQL itself does not handle file uploads. Their solution was to have a POST or PUT endpoint somewhere and to return the info about the uploaded file as GraphQL.
A downside of GraphQL: it is hard to predict the costs of a query. You can ask for adresses of contacts living at addresses of contacts and so on: you can kill the server that way. You could prevent that by, for instance, limiting the depth of the query.
There are reasons to stay with REST:
- GraphQL is not a silver bullet. Yes, it has advantages.
- The django/python tooling is still not very mature.
- Determining the cost of a query is hard to predict beforehand.
But: just use GraphQL, it is fun!
from Planet Python
via read more
No comments:
Post a Comment