We are currently experiencing a mind-shift in how we approach developing web services. While these idea are not new, the development of GraphQL, Relay (Facebook) and competing technologies like Falcor (Netflix) are currently sparking great excitement especially in and around the greater JavaScript community and amongst people who are equally frustrated about and burnt-out by REST as I am. Don’t get me wrong… I’ve been working with and creating REST APIs for a while now and trying to build applications around them. But it never felt quite right. There are quite fundamental problems in how we currently approach web services: We are trying to squeeze our data models into strict architectural models that are lying about the true form of our data.

Most of our data is strictly structured and hierarchical in some way or another, often including references to other sets of information in our data store. If this is true, then why are we not respectfully treating our data as such?

We are currently either building bloated, partly generic interfaces that contain enormous amounts of mostly irrelevant information or we build non-reusable ad-hoc endpoints, artificially increasing the complexity and maintenance burden of our applications.

GraphQL takes a wholly different approach. Instead of building around a concept of individual resources, it allows you to expose your entire data model through a well defined schema. You can then access your data by specifically requesting individual fields, optionally traversing into data references and fetching related information as needed. All in a single request and through a self-explanatory syntax that was inspired by JSON. Well, it actually is JSON with some extra syntactical sugar and without field values. As I said earlier, these concepts are not exactly new. JSON Like-APIs as well as other similar concepts for structured web services have been around for a while now.

The list of benefits of this approach is rather long. Some of the most critical points are the enormous flexibility, great extendability and with that, ease and increased pace of development. What’s most significant for me though is the fact that this finally allows true decoupling. We’ve been talking about “Headless Drupal” or “Decoupled Drupal” for a while now. Up until now, proper decoupling is not truly possible without removing Drupal from the negotiation or at least moving it in the background even further. “Why is that?” you might ask. Right now, when seemingly decoupling your frontend, you are actually still coupling it to your specific APIs and thereby, the underlying structure. This becomes a larger problem as your application grows or you want to change or extend it’s features.

What makes GraphQL special is its easily understandable syntax, its toolchain and, most importantly, the vast and ever-growing JavaScript and especially React community that is quickly adopting and celebrating it. The question is not IF, but WHEN GraphQL or one of its competitors will become mainstream.

Why is this such a big deal for Drupal? Drupal has been struggling to live up to its promises when it comes to enabling proper decoupling as described earlier. This is really annoying given its great potential. I can’t accept that. I want Drupal 8 to be the go-to data-hub and editorial and administrative platform that backs your and everyone else’s applications. Imagine the joint power of a uniform and flexible web service language and an incredibly flexible and configurable backend architecture that is Drupal 8. Image the possibilities. the pace of development and performance arising from a schema-driven web service that defines itself through an adapter that can traverse and translate the data definitions of your site’s configuration, content, listings and even mutations. Instead of crafting ad-hoc interfaces or complicated, partly generic resources, you will simply build up your API by configuring data types e.g. through the content type administration interface as well as listings through the Views interface or abstract mutations through the Rules interface.

This is GraphQL on Drupal. In the future, you’ll be able to truly focus on your application instead of pulling out your hair, trying to get web services right.

If you are interested in this topic, there is a live demo of GraphQL on Drupal waiting for you on YouTube.

I am currently working hard on writing a PHP implementation of the GraphQL specification as well as a Drupal 8 module that exposes Drupal’s data model as a schema. You can follow this effort on the GraphQL Module page.

… and in case you missed the #driesnote at DrupalCon Barcelona (GraphQL introduction starts at 1:01)