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!
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):