Part 1 | Part 2

Table of Contents

Over the last five years, decoupled Drupal has grown from a fringe topic among front-end enthusiasts in the Drupal community to something of a phenomenon when it comes to coverage in blog posts, tutorials, conference sessions, and marketing collateral. There is now even a well-received book by this author and a yearly conference dedicated to the topic. For many Drupal developers working today, not a day goes by without some mention of decoupled architectures that pair Drupal with other technologies. While Drupal’s robust capabilities for integration are nothing new, there have been comparatively few retrospectives on how far we’ve come on the decoupled Drupal journey.

Recently, your correspondent (Preston So, Editor in Chief at Tag1 and author of Decoupled Drupal in Practice) sat down for a no-holds-barred discussion about decoupled Drupal on Tag1 Team Talks with three other early insiders in the decoupled Drupal mindspace: Sebastian Siemssen (Senior Architect and Lead React Developer at Tag1 and maintainer of the GraphQL module), Fabian Franz (Senior Technical Architect and Performance Lead at Tag1), and Michael Meyers (Managing Director at Tag1).

During the conversation, we spoke about the unexpected ways in which decoupled Drupal has evolved and where it could go in the near and far future. In this two-part blog series, we look back and peer forward into decoupled Drupal’s trailblazing and disruptive trajectory in the Drupal ecosystem, starting with Sebastian, who created Drupal’s GraphQL implementation, and Michael, who has witnessed firsthand the paradigm shift in Drupal’s business landscape thanks to the benefits decoupled Drupal confers.

Defining decoupled Drupal

As it turns out, defining decoupled Drupal can be tricky, given the diverse range of architectural approaches available (though these are covered comprehensively in Preston’s book). In its simplest form, decoupled Drupal is an idea centered around the notion of employing Drupal as a provider of data for consumption in other applications. In short, the “decoupling” of Drupal occurs when developers opt to utilize Drupal data by issuing requests to APIs that emit JSON (or XML) rather than through Drupal’s native presentation layer.

As Fabian notes in the webinar, there are multiple “flavors” of decoupled Drupal that have emerged. Fully decoupled Drupal implementations aim to replace the entire presentation layer of Drupal with a distinct application. Progressively decoupled Drupal, an idea first promulgated by Drupal project lead Dries Buytaert in a 2015 blog post, recommends leveraging API calls to provide for components in the existing Drupal front end rather than an entirely separate presentation layer.

The pros and cons remain largely unchanged

Decoupled Drupal presents both advantages and disadvantages that are worth considering for any implementation, and these are also covered in Decoupled Drupal in Practice. Fully decoupled Drupal, for instance, means jettisoning a great deal of what makes Drupal such an effective web framework by limiting its feature set substantially to solely the APIs for retrieving data and an administrative interface for content management.

Though decoupling Drupal inevitably means losing certain functionality, such as contextual links, in-place editing, and layout management, it does confer the opportunity to create something entirely custom atop the data model that Drupal provides, as Sebastian states in our Tag1 Team Talks episode. Nonetheless, while decoupled Drupal does introduce unprecedented flexibility, it also goes beyond a simple separation of the presentation layer from the data layer by rendering Drupal more replaceable. The notion of replaceability does belie an undercurrent of anxiety surrounding decoupled Drupal, and it presents risks for Drupal’s position in the CMS market.

A competitive advantage for commercial Drupal

Nonetheless, from the commercial standpoint and the customer perspective, there is no question that decoupled Drupal is a boon for ambitious digital experiences. For instance, during our conversation, Michael argues that decoupled Drupal actually represents a competitive advantage for Drupal in the commercial space rather than an erosion of its value. The narrative of integration in which Drupal has always trafficked has long been influential in swaying skeptical stakeholders. In short, in this view, Drupal’s core REST API, JSON:API, and GraphQL only strengthen this flexibility to integrate.

As a matter of fact, Tag1 Consulting’s yearslong work with Symantec supports this notion. Together with Tag1, Symantec embarked on a migration from version to version of Drupal in a nontraditional way that was only made possible thanks to decoupled Drupal technologies. By providing multiple front ends across Drupal versions, Symantec and Tag1 succeeded in both accelerating and effectively managing the migration to Drupal 8. Michael notes that from a client standpoint at Tag1, decoupled Drupal has been a valuable and sought-after asset; if anything, it has only increased evaluators’ interest in the platform.

Aside: Our stories in decoupled Drupal

Sebastian, Fabian, and I also reminisced about our respective stories in the decoupled Drupal landscape and how it has impacted the trajectory of our work even today. Arguably among the first in the Drupal community to leverage a decoupled architecture, Fabian admits building a decoupled site that consumed unstyled HTML snippets as far back as 2009, with other data coming from multiple sources. We can certainly forgive the fact that he opted to use Flash for much of the front end in that build.

Early in 2015, Sebastian found that the release of GraphQL by Facebook as a new specification made everything “click” for him as one of the crucial gaps in Drupal’s APIs. That same year, Sebastian began working on GraphQL for PHP, basing much of his ideas on the just recently open-sourced GraphQL JavaScript library. Thanks to Sebastian’s tireless work, the GraphQL module for Drupal first appeared as a codebase on Drupal.org in March 2015 and has since skyrocketed in interest and popularity.

My own journey is much less glamorous, as I assisted Drupal project lead Dries Buytaert with his initial thought leadership on the subject of decoupled Drupal back in 2015. At the time there was considerable hand-wringing about what disruptive advances in the front-end development world could mean for Drupal. Over the course of time, my perspectives have evolved considerably as well, and I believe there are many excellent use cases for monolithic implementations, something I stress in my book about decoupled Drupal. Today, I help run the biggest and oldest conference on decoupled and headless CMS architectures, Decoupled Days, which is now entering its fourth year.

GraphQL as a game-changer

One of the key questions for decoupled Drupal practitioners has been how to leverage the best that Drupal has to offer while also accessing some of the best ideas emerging from the API and front-end development spaces. For instance, among Drupal’s most notable selling points is the fact that not only does Drupal benefit from an excellent administrative interface; it also offers a robust customizable data model that can be crafted and fine-tuned. Entity API and Field API, for instance, have long been some of the most vaunted components of the back-end Drupal developer experience.

Tag1 recently found this with a project that employs Laravel, a more lightweight PHP framework for websites that is far less opinionated than Drupal. Light layers of entities and fields were required for the Laravel project, and Fabian remarks in our recent webinar that these are particularly straightforward to implement and validate in Drupal. GraphQL adds another fascinating dimension to this by allowing Drupal to handle the heavy lifting of important features like field validation while permitting client-tailored queries.

GraphQL queries at scale

Sebastian describes GraphQL as a reversal of the traditional relationship between the server and client. Rather than the client being forced to adhere to what the server provides, the server declares the data possibilities that it is capable of fulfilling, and based on these catalogued possibilities, the client defines exactly what it needs on a per-request basis. The client sends the query to the server in a particular format, which Sebastian characterizes as much like the “JSON you want returned from the API but only the keys.” Thereafter, the GraphQL API inserts the values and returns a response with precisely the same shape.

This brings us to one of the most fascinating aspects of GraphQL within the Drupal CMS, which often utilizes deeply nested relational data structures that are uniquely well-suited for modeling into a graph — which is the very core of what GraphQL does. One of the best aspects of GraphQL, moreover, is its capabilities for schema and query validation, with which we can prevent distributed denial-of-service (DDoS) attacks that attempt to overload queries with many nested layers by checking and analyzing the complexity of queries ahead of time, a task that is much easier thanks to the predictability of GraphQL schemas.

What about JSON:API vs. GraphQL?

While the story of GraphQL has been long-running in the Drupal ecosystem, it’s important to note the other big player in Drupal’s web services: JSON: API, which was just this year introduced into Drupal core. One of the biggest reasons why JSON:API has gained prominence is its relative stability and its high amount of documentation. Sebastian argues that React developers coming from their ecosystem are more likely to be familiar with GraphQL already, which also helps elevate its status within the decoupled Drupal ecosystem.

GraphQL v4 and custom schemas

One of the most anticipated releases of the GraphQL module is GraphQL v4 for Drupal, which means several significant changes for the ever-evolving GraphQL module. In the latest version of the GraphQL module, the GraphQL schema is fully in the control of Drupal developers, which is a substantial change from previous releases. After all, one of the best selling points for using GraphQL in the first place is schema customizability.

According to Sebastian, this means that you can decouple Drupal on the API access and contract level rather than foisting the data model and data internals of Drupal on the resulting GraphQL API, which may cause confusion among developers of consumer applications like React implementations.

Conclusion

Perhaps the most intriguing development in the long-running saga of decoupled Drupal is the diversification and proliferation of a wide range of approaches, like GraphQL, that improve the developer experience in Drupal significantly. Besides its obvious benefits of greater flexibility on the side of developers, moreover, Drupal users and agency customers are also discovering the advantages of decoupled Drupal for a variety of use cases.

As we recently discussed during our conversation, a mix of both nostalgia and forward thinking, decoupled Drupal is here to stay. Whereas in years past this statement may have caused considerable anxiety in the Drupal community, today it is emblematic of the ongoing explosion of options and capabilities that decoupled Drupal engenders for Drupal developers. But in the second installment in this two-part series, Fabian, Sebastian, and I discuss some of the anxieties and worries we share about decoupled Drupal, before attempting to predict what could come next for this fast-evolving paradigm.

Special thanks to Fabian Franz, Michael Meyers, and Sebastian Siemssen for their feedback during the writing process.

Part 1 | Part 2

For more on decoupled Drupal, see our Decoupled Drupal page.

Photo by Jesse Bowser on Unsplash