Part 1 | Part 2

Table of contents

As another decade comes to a close in Drupal’s long and storied history, one important trend has the potential to present amazing — or unsettling, depending on how you look at it — opportunities and shifts in the Drupal ecosystem. That trend is decoupled Drupal. Nowadays, there is no limit to the content prolifically produced by the community about the topic, whether it’s in the form of a comprehensive book on the subject or a conference focused on the theme. Today, decoupled Drupal implementations seem, at best, to be a door presenting new approaches and ideas, and, at worst, here to stay for good without proper consideration for potential externalities.

On one of the latest Tag1 Team Talks episodes, we gathered four insider experts on decoupled Drupal, including yours truly (Preston So, Editor in Chief at Tag1 and author of Decoupled Drupal in Practice), 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). Over the course of the wide-ranging discussion, we revealed some of our reminiscences, misgivings, and hopes about decoupled Drupal in the years to come.

What trajectory will decoupled Drupal take over the coming decade? In the second part of this two-part blog series, we take a closer look at how decoupled Drupal has already revolutionized how we think about key features in Drupal with Fabian and Sebastian looking to reshape how Drupal renders markup and dynamic components and all of us highlighting security as one of decoupled Drupal’s competitive advantages.

Anxieties and aspirations for decoupled Drupal

One of the subjects we focused our attention on was our feelings on the current state of decoupled Drupal and how it is impacting the way we implement Drupal architectures today. Fabian, in particular, has mixed feelings about decoupled Drupal at present. While decoupled Drupal confers significant advantages, as we saw in the previous blog post, it also can lead to skepticism about the disadvantages it introduces. I wrote about the risks and rewards of decoupled Drupal back in 2016, and many of these pros and cons still resonate deeply today.

The loss of administrative features that are present in Drupal’s presentation layer but absent from decoupled front ends is an important rationale for many who believe monolithic architectures remain wholly viable. For instance, Fabian cited as evidence a recent Tag1 project that leveraged a decoupled Drupal architecture but also required some reinvention of the wheel to reimplement contextual links, a key front-end Drupal feature, in the decoupled presentation layer. Nonetheless, decoupled Drupal remains an excellent choice for mobile applications, digital signage, and even conversational interfaces.

Overly different front-end worlds

One of the issues with decoupled Drupal is the fact that developers are attempting to solve problems that, according to Fabian, should be solved within Drupal itself.

As Fabian argues in our recent webinar, “One of the mistakes we made in core is that we are mixing data and presentation within our render trees and entities.” The fact that the experience of React developers differs so substantially from Drupal theme developers further highlights this issue.

Web Components for better encapsulation

At DrupalCon Amsterdam, Fabian presented a session about Web Components that proposed a path forward to narrow the gap between front-end developers who are pursuing new paradigms such as React and Drupal developers who wish to implement components in Drupal front ends. Web Components are compelling because they provide for better-encapsulated code but still allow for data to come from any source, including Drupal.

In Fabian’s view, Drupal needs to do much more to bridge the gap between new front-end ecosystems and Drupal, together with a finely tuned developer experience that doesn’t require significant new learning but does allow for better closeness between the front end and the back end. For Fabian, it is essential that the Drupal community scrutinize some of the approaches to componentization found in JavaScript ecosystems.

The age-old debate: Decouple Drupal itself?

Sebastian argues that spitting the back end and front end of Drupal more at the kernel level is the right approach. There is significant weight in Drupal’s codebase that presents challenges not only for the administrative interface that many Drupal users work with on a daily basis but also the API layer within Drupal.

In fact, one of the original goals of the Web Services and Context Core Initiative (WSCCI), whose trajectory I cover extensively in Decoupled Drupal in Practice, was to recast core as a slim kernel that provides low-level functionality completely isolated from user interface components.

What’s next for decoupled Drupal?

So what’s next for decoupled Drupal? How will we as practitioners modify the approaches we take and the paradigms we utilize as decoupled Drupal continues to gain steam across the community? For this, I requested help from Fabian and Sebastian to offer their perspectives on some of the possible directions that decoupled Drupal might take as we traverse new territory.

Security remains a competitive advantage

One of the more enticing elements of decoupled Drupal is the fact that it can facilitate favorable security outcomes. Thanks to the rapidly evolving advantages offered by new JAMstack (JAM stands for JavaScript, APIs, and markup) and serverless approaches, security can become much less of a concern in decoupled architectures.

With a content server like that provided by Drupal, argues Fabian, we can feasibly implement JAMstack architectures that yield static HTML pages as the end result rather than dynamic applications with potential security vulnerabilities or, worse yet, a monolithic architecture that means an attacker could gain access to the entire Drupal system from end to end by exploiting a front-end weakness. After all, static HTML is completely secure, as there is no executable code. For Fabian, this is one of the most important and often overlooked advantages of the decoupled Drupal approach.

An approach for dynamic components

These innovations in the front-end development landscape comprise some of the rationales that Fabian cites for taking a closer look at the JavaScript community and how they handle encapsulated components. The crucial missing piece in any JavaScript implementation is sourcing data — and this is an area that Drupal can improve.

Sebastian agrees that decoupling data from internal Drupal objects like fields and entities could resolve many issues in Drupal, but he also argues that one of the key disadvantages of Drupal in its current conception is its push-based model. As an illustration of this, when Drupal fulfills a request, it executes a massive processing engine to pull data from sources and feed them into a rendering engine.

He goes on to argue that reversing Drupal’s render pipeline approach and pulling data from graphs (e.g. through GraphQL) as the template engine needs it, just in time, would allow Drupal to evolve to a more modern, pull-based approach. To Sebastian, this pull-based mechanism is precisely what an API-first architecture promises, and he cites recent innovations surrounding GraphQL in Twig as the initial steps toward this exciting vision.

Further in the future: A more real-time Drupal

One of the areas that has long fascinated me is the potential for Drupal to evolve into a more real-time system that confers significant advantages when it comes to dynamic components. Fabian argues that Web Components are a key step on the road to real-time Drupal, and a “components everywhere” approach could allow for this to occur. With a component-based approach, the only additional step necessary would be a Node.js server that updates components whenever data sees updates as well.

For all of Drupal’s benefits, real-time capabilities remain elusive. As Sebastian rightly states, real-time approaches are largely infeasible in PHP. After all, real-time data is something that Drupal is ill-equipped to handle itself; any real-time functionality needs to be handled on top of Drupal in a non-PHP layer. One option that Sebastian suggests is the combination of a Node.js server, Drupal’s PHP environment, and Redis, which would facilitate a push-based approach. Saving in Drupal could send a notification to a PubSub environment such as Redis or Kafka, and a Node.js microservice could update the client through a WebSocket.

Though this would mean forwarding Drupal’s APIs to a Node.js environment, fortunately, there are several ways to approach this in a way that keep Drupal’s benefits such as granular caching in Drupal 8, which is provided through the cache tag system. And the closer the data source is to an API like that built in GraphQL, more can be done to optimize the database queries and caching. Fortunately, GraphQL comes with WebSocket and subscription support, and it would be a compelling choice given the ongoing work in the GraphQL specification to send GraphQL queries and subscriptions in the same response.

Conclusion

Thanks to decoupled Drupal, the Drupal community is in the midst of a renaissance that is revolutionizing the way we think about the front end of Drupal while simultaneously challenging our long-held assumptions about how Drupal should look and operate. While this is a testament to Drupal’s considerable longevity, it also presents obstacles if we wish to guarantee the future of Drupal for the coming decade. Fortunately, owing to the vast amount of resources surrounding decoupled Drupal, including the book Decoupled Drupal in Practice and even a conference dedicated to the subject, more and more discussion around the topic will yield significant fruit for the promising future of Drupal.

While no one can prognosticate how decoupled Drupal will look in 2030, at the end of this current decade, we can certainly see that the story of decoupled Drupal is only just getting started. I strongly encourage you to check out our recent Tag1 Team Talks episode to learn more about what could influence Drupal’s trajectory substantially in the coming years. I, for one, believe that though we have come a long way, we still have much distance to cover and much thinking to do in order to prepare for a more decoupled Drupal. Nevertheless, the solutions recommended by Fabian and Sebastian excite me just as much as I hope they have inspired our readers too.

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