Data, database, data fetching, data requests, data retrieving, data receiving... all modern web apps — fully or progressively decoupled front-end applications — have an insatiable “appetite” for data. And satisfying this particular “hunger”, with no compromise on performance, is the “mission” that GraphQL on Drupal 8 — the module — has been invested with.
Retrieving the requested data with as little time and resources used on round trips to the server as possible. With no under- or over-fetching, with no need for versioning.
In short: the module “exploits” all the limitations that the Restful approach started to show in addressing well-known data issues; it came out as a result of Dries Buytaert's advice and forecast on advancing Drupal's web services.
But let's not beat around the bush anymore and dive right in:
GraphQL This... GraphQL That... But What Is GraphQL After All?
It's Facebook's patented technology created in 2015.
And app layer query language designed to revolutionize the way data gets retrieved, interpreted and formatted: all these processes take place based on a GraphQL schema!
Approaching the data in terms of graphs and exposing those graphs in a schema guarantees that the caller's data request is identically structured as the delivered answer.
Not to mention that the same caller gets to formulate his data requests more explicitly and specifically thanks to GraphQL.
No wonder that front-end Drupal developers have started to perceive it as a powerful rival to REST! To the standard REST approach to retrieving data in apps built with headless Drupal 8.
In this respect, let's briefly recap just some of its “luring” features:
- it perfectly matches the data request's structure with that of the delivered response
- it queries the requested data based on s self-documented, automatically generated data exposure schema
GraphQL & Drupal: A Duo Powering The Future of Decoupled Drupal
Take GraphQL as the intermediary used in decoupled Drupal projects between the JavaScript front-end and the Drupal back-end. The one invested with the role of smoothing and streamlining the interaction of the decoupled front-end with the Drupal data source.
A role that used to be played, in all Drupal decoupled apps, exclusively by the RESTful web services, remarkably well developed in Drupal 8. Till the traditionally used REST architecture started to prove its failure in addressing data access issues.
And GraphQL on Drupal 8, the dedicated GraphQL module, started being built.
The improved overall performance, that this new approach to retrieving data promises, derives from:
- GraphQL's way of retrieving data based on a schema
- its entire system of types and fields
… which guarantees predictable responses only (the client-side apps are enabled to request for specific data) and, implicitly: no round trips and no extraneous data.
A responsible use of server resources.
Moreover, in case of complex, hierarchical data, not only that the caller gets to shape a “straight to the point” request, but it gets to ask for all the needed data on the same query!
An efficient use of server power especially when your decoupled Drupal app's front-end requests loads of data in a context of slow mobile internet connection.
GraphQL on Drupal 8: Your Data Graph Conveniently Exposed in a GraphQL Schema
And then... the GraphQL module was born!
Not yet part of the Drupal core, but powerful enough to allow front-end Drupal developers to use it to its full potential in their decoupled Drupal projects.
The main “mission” that its maintainer, Sebastian Siemssen, invested it with was: to turn Drupal into a GraphQL-powered data hub for decoupled front-end apps, by implementing a schema. A GraphQL schema exposing the available field types and entity.
Practically via TypedData API your Drupal 8 site's data graph becomes more “readable” for the GraphQL library.
This way, the client-side app gets to request for more than specific data/field values and to receive precisely the required info. And this streamlined data fetching process with GraphQL on Drupal 8 can only lead to zero bloated responses.
There's more!
We can't be talking about “a” module, but a whole ecosystem of submodules that you can read more about on Drupal GraphQL Github:
- GraphQL Content
- Entity Reference
- Breadcrumbs
- Boolean
- Content Mutation
- Link
- Image
- Menu
- File
- Block
- Views
Have you already harnessed the full potential of GraphQL on Drupal 8 to fuel your web apps with? If not, why hesitate?
Why do you still think it might not be a robust enough alternative to the traditional REST approach to data fetching?
