PyGrunn: lessons from using GraphQL in production - Niek Hoekstra & Jean-Paul van Oosten

Tags: pygrunn, python, django

(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!

 
vanrees.org logo

Reinout van Rees

My name is Reinout van Rees and I program in Python, I live in the Netherlands, I cycle recumbent bikes and I have a model railway.

Weblog feeds

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):