Skip to main content

Blog Post

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

Headshot

Meet team member, Edward Chan

Edward brings four years of Drupal and full-stack experience to his role as a Developer at Mediacurrent. He has experience in all tiers in the Drupal stack- from front-end theming, to custom module development, to performance/scalability and migrations. One of his main interests right now is to dive deeper into Drupal 8 and headless Drupal architecture using modern frameworks and libraries. Edward is also an active attendee at regional Drupal camps, DrupalCon, and other technical meetups.

Edward started his Drupal career at The Gilder Lehrman Institute of American History, where he was first exposed to Drupal. During his time there, he was part of a 2-person tech team that helped enhance and scale the website which  generated 100% increase in traffic year over year. He then joined NorthPoint Digital as a consultant and implemented Drupal solutions based on client needs. During his tenure there, he gained immense experience with custom module development in an agile environment, and even had the chance to contribute his first patch to a contrib module (Social Media Aggregator)! He also further developed his skills by diving into some modern technologies such as React and Node.js to work with Drupal data.

Born and raised in New York City, Edward is accustomed to the fast-paced lifestyle and enjoys roaming around NYC searching for the next best cup of coffee, finding the next restaurant serving exotic foods, as well as attending Knicks games.

Learn more about Edward >

Related Insights