GraphQL Meets Drupal

Web applications today have many things in common, but at the core, there is only one thing that drives these applications - a thirst for data.

The topic of GraphQL is a big one - especially when deciding the future of Drupal web services - as was brought up by Dries Buytaert himself in his blog post, “Advancing Drupal’s web services. ”Dries states, “I believe that GraphQL and JSON API in core would be a big win for those building decoupled applications with Drupal...”

After attending Sebastian Siemssen’s session on “GraphQL meets Drupal” at DrupalCon NOLA, it was immediately apparent to me that whilst traditional REST is the more popular approach for fetching data, it may not be the best in solving many of the problems of handling hierarchical data. In comes GraphQL, a database querying language built by Facebook, to solve the limitations of REST - which may include overfetching, under fetching, multiple round-trips, and versioning issues.

A non-hypothetical real-world example

To demonstrate how GraphQL is advantageous over a traditional REST approach, Sebastian uses a Star Wars API as an example in which several pieces of information are desired - the name of the person, movie appearances (by name of the movie), and the home planet. In a traditional REST approach, a response object may return unnecessary data not required or used in an application (see http://swapi.co/api/people/1/ as an example), which results in overfetching. Since Drupal has a very heavy bootstrap and is continuously requesting resources, performance can quickly be impacted.

If we wanted to fetch more specific information based on a value returned from the object (let’s say, the “homeworld” of the person), another round-trip to the server will be required to access the endpoint for the “homeworld” name (see http://swapi.co/api/planets/1/). Multiple round-trips to the server are required when fetching complex, relational data structures.

In addition, maintaining several front-end applications (iOS, Android, JS) that use data served from the same API each might require different views and API versions, which makes versioning equally as important as preventing overfetching and multiple round-trips.

Ideally, we would want the specific information we desire in a single request in the same shape requested in and to do so, we need to think of data in terms of graphs.

How to fix this?

Try GraphQL! The GraphQL module helps us solves these problems. It generates a self-documented schema to expose the Drupal data graph (so it can be read by the GraphQL library) through the TypedData API. If you want to fetch the value of a field (and only that field, nothing else) on a specific node, GraphQL will fetch the node through the Entity API, extract the requested fields from the entity, and output the result in a formatted JSON. This prevents a bloated response of all the other fields and information associated with an entity that is not needed.

Pro-tip: There is a tool called GraphiQL (pronounced “graph-i-cal”) developed by Facebook to provide a functional IDE for your schemas.

To go more in depth, a more detailed explanation of how GraphQL works with Drupal can be accessed in the recording of Sebastian Siemssen’s session.

In Summary

This session was very much enjoyable, as it addresses important data access issues that come up more and more frequently in modern web applications. In the limited time he had, Sebastian Siemssen did a tremendous job in introducing GraphQL and demoed some complex Drupal queries using the GraphiQL interface. It was a valuable session and one that should not be missed if you are looking to optimize your applications.

More Resources on GraphQL

Additional Resources
Brain Food for Your Post-DrupalCon Slump | Blog Post
8 Insights and Useful Snippets for the D8 Rest Module | Blog Post
Introducing Decoupled Blocks Module: Decoupling In Drupal 8 Based on a Proven Model | Blog Post