Advantages and Disadvantages of Decoupled Drupal
For far too long, decoupled Drupal has been characterized as either an unexplored wilderness or an untested fad, compounded by a constantly shifting landscape of best practices and established standard approaches. Since I first started presenting to audiences about this groundbreaking trend in Drupal architectures, available literature has both remained elusive and become quickly obsolete, including my own blog posts on the topic.
Fortunately, this November, the publication of my new book, "Decoupled Drupal in Practice,"marks the first comprehensive guide to decoupled Drupal, its architectures, and its implementation on the market today. With a foreword by Acquia CTO and co-founder Dries Buytaert, "Decoupled Drupal in Practice" is now available for preorder on Amazon and on Apress and is a must-have for any Drupal practitioner's bookshelf.
“Decoupled Drupal in Practice” covers all of the distinct strands of decoupled Drupal from the standpoint of both marketers and developers, with a description of the history and background of decoupled Drupal architectures. It includes a full description of foundational Drupal web services like core REST, JSON API, and GraphQL; an analysis of available authentication methods; and tutorial-focused approaches to building consumer applications in React, React Native, Angular, Vue, and Ember.
For engineering executives and marketing professionals who are seeking more insight into whether decoupled Drupal is right for them, I have excerpted two chapters from the book below that delve into the risks and rewards of decoupling Drupal. To gain more insight into decoupled Drupal, how it came to be, and whether it is right for you, please order your copy today.
Advantages of Decoupled Drupal
Progressively decoupled Drupal has its own benefits, which are outlined throughout this chapter. These include pipelined development but also the ability to maintain a monolithic architecture without multiple points of failure, as well as mixed experiences in which differentiated levels of interactivity can be provided for the benefit of the user.
"Write once, publish everywhere" is rapidly becoming a popular tenet in marketing and publishing in the omnichannel landscape. Increasingly, content providers and publishers are seeking to take advantage of diverse mediums to deliver their content to a growing array of experiences. In these scenarios, Drupal is the hub for a constellation of experiences, all ingesting content from a single source of truth, whether that hub is a full Drupal site (with optional progressive decoupling) or a fully decoupled Drupal repository.
It is important to emphasize here that Drupal does not need to be fully decoupled for content syndication to succeed when it comes to building experience ecosystems. Many Drupal sites that are monolithic and end-to-end also expose data for consumption by other applications. Indeed, this is how Drupal project lead Dries Buytaert recommends that architects use Drupal in a decoupled way: as a public-facing Drupal site which acts also as a central data source for consumer applications. This maintains Drupal's end-to-end contiguity and also retains Drupal's front-end benefits on the Drupal website itself.
Separation of Concerns
Web development has long contended with the issues surrounding the separation of concerns between structured data and its presentation layer. Whereas structured content and its delivery constitute the structural skeleton of Drupal, templates and their logic make up the presentation of Drupal content. Even in monolithic Drupal, one can easily draw a distinction between the layers which make up key back-end features of Drupal (e.g. the database itself, the database abstraction layer) and its front-end functions (e.g. the Twig theme layer).
Although in monolithic and progressively decoupled Drupal, this separation of concerns is implicit and largely invisible to the user, in fully decoupled Drupal it becomes an explicit split between structured content, handled by Drupal, and its presentation, handled by consumer applications. As such, by exposing data to the front end in JSON or in XML, presentation and aesthetics become the domain of the consumer applications that create their own experiences using Drupal content, separately from the default Drupal front end.
The aforementioned RESTful Panels module challenges this paradigm in the fully decoupled context, but the injection of presentational logic from Drupal alongside structured content challenges the separation of concerns that fully decoupled Drupal touts in the first place.
User-Centered User Experiences
The benefit of improved user experiences is perhaps the most polemical of the advantages that decoupled Drupal confers, because good user experience results from effective design and development, not necessarily from architectural decisions. Nonetheless, decoupled Drupal does confer the advantage of an improved user experience from the fact that experiences better catered to users' needs can be crafted by undertaking a decoupled Drupal architecture.
Front-End Developer Experience
In pipelined development, teams with different skill sets can work in parallel on different components of the implementation without impeding each other's work or compromising the integrity of the project. Decoupled Drupal also opens the door to a pipelined development process in which a front-end team can build applications against a dummy web service API used solely for testing but not actually completed, while a back-end team can construct the back end which exposes that API and the underlying processes yielding it.
Fully decoupled and progressively decoupled Drupal architectures both allow teams to produce work at their own respective velocities. For instance, whereas an Ember developer would be proficient with Handlebars, they may not understand the systems that provision web service APIs in Drupal, at which point a Drupal developer can contribute. In this fashion, a front-end developer is no longer hamstrung by the complexities of Drupal's theme layer and can control markup and rendering, while Drupal developers can focus on their expertise on the back end and craft a robust RESTful API.
In this chapter, we examined some of the rewards incurred when decoupling Drupal, whether in the fully decoupled or progressively decoupled way. These include content syndication, where an omnichannel landscape helps realize the dream of "write once, publish everywhere," and a separation of concerns, where structured content is distinct from its presentation.
In addition, both developers and users benefit from experiences that are fine-tuned to their requirements, whether it is greater interactivity, a particular device, or a set of technologies. Finally, perhaps the most relevant for both fully decoupled and progressively decoupled approaches is the promise of pipelined development, where developers of different specializations can work in parallel on distinct components.
Disadvantages of Decoupled Drupal
With all of the buzz and favorable attention surrounding decoupled Drupal at present, it can be easy to sidestep the pitfalls of decoupling Drupal without evaluating them intensively. Choosing to use Drupal only for its web service capabilities and as a content repository can endanger your entire architecture if you need Drupal's front-end functionality or other critical functions that rely on the presence of Drupal's default front end. Other risks apply as well.
Additional Point of Failure
As a result, introducing an additional hosting stack into your organization's infrastructure may not only be difficult for those of more modest means; it also introduces an additional point of failure in your architecture. For instance, if the Drupal site acting as a web services provider fails without proper caching, the data your application conveys to the user may be outdated or inaccessible. By the same token, consumer applications that are the sole conduit for Drupal content and experience downtime will lead to a situation where users have no means of accessing your content, unless your Drupal site is also publicly accessible.
Security and Input Sanitization
Contextualized Editing and Administration
Some of Drupal 8's most compelling functions include in-place editing (known as the Quick Edit module) and configuration menus accompanying certain page components (known as Contextual Links), a few of the modules that comprise contextualized tools for Drupal administration. During content preview in a monolithic architecture, these interfaces permit site builders and content editors to adjust content while simultaneously viewing its live result or to access administration pages from the comfort of the visual preview.
These contextualized tools, in a fully decoupled Drupal architecture, are no longer available, unless they are reconstructed on the consumer application, which leads to a duplication of functionality. As such, employing a distinct front end from Drupal's for the web experience transfers responsibility over deploying such interfaces to the front-end developer, who can either provide replacements or replicas of these tools or note its unavailability in the editor's experience. The progressively decoupled approach somewhat mitigates this, though it suffers from a "black box" problem in which material contained within "decoupled" areas of the page cannot be edited or administered according to normal Drupal administrators' expectations.
Layout and Display Management
Among Drupal 8's features are core and contributed modules that confer features for layout and display management, which offer a spectrum of options to provide variable content displays (Display Suite) or construct layouts consisting of content "panes" (Panels). Because they require significant control over Drupal's markup, these modules need to be tightly coupled to Drupal's presentation layer.
Removing modules like Panels and Display Suite from the editorial equation means that layout management becomes a developer concern, not an editor's. This results in considerable challenges for marketing teams that do not have access to developers who can assist in implementing layout changes. To allow editors to continue manipulating layouts rather than just content, your organization will either need to employ Drupal's presentation layer, rebuild layout management as a feature in the consumer application, or expose layout configuration in the form of ingestible data via modules like RESTful Panels.
Previewable Content Workflows
Among the most important underpinnings of a robust CMS is the capability to create and operate along editorial content workflows, whereby one can conveniently preview content states such as drafts and "in review" without prematurely posting potentially embargoed content.
Jettisoning Drupal's functionality for content previews and content workflow by employing a different front end from Drupal's translates into considerable challenges if an editorial team desires a previewable content workflow, to which they may be accustomed after years of working within a traditional CMS. Several roundabout alternatives exist, such as provisioning an additional private staging environment to allow for different content to be deployed, or extending web services to expose differentiated content accessible via secondary authentication or unique query parameters.
Another key feature of Drupal is its robust notification system, which displays information about any issues arising during a Drupal system process, especially severe system errors that demand immediate attention. While a REST resource is available within Drupal to fetch watchdog logs, these provide only a limited amount of the possible issues that administrators should scrutinize. Moreover, Drupal system messages frequently highlighted at the top of rendered pages are inaccessible in a fully decoupled Drupal environment.
To maintain unimpeded awareness of potential problems that occur in Drupal, especially ones that may impact the transmission of data to consumer applications, it is important to watch system messages within the Drupal back-end interface carefully, as without substantial custom code, these messages will be unavailable. In a progressively decoupled setting, providing these messages are less of a concern, as Drupal does handle some of the rendering and only requires an area where such system messages can be visible.
Monolithic Performance Benefits
One of the most compelling features of Drupal 8 is cache tags, also known as cacheability metadata, which allow developers to define dependencies on data managed by Drupal and permit cache invalidation of items that rely heavily on granular content contained within them. For instance, the BigPipe contributed module abbreviates the time to first paint by providing progressive loads of pages based on the differentiated cacheability of respective page components.
Accessibility and User Experience
Finally, but perhaps most importantly, Drupal's efforts on accessibility and user experience have included utmost consideration for markup and how it is presented to people living with disabilities and users of assistive technologies. For example, Drupal's use of ARIA roles and other techniques ensure that all Drupal content is available for users of screen readers. Moreover, Drupal's focus on usability across its history means that anyone using Drupal's Form API is certain to benefit from a set of standardized and battle-tested best practices.
Though decoupling Drupal can translate into wide-ranging dividends for your team and for your goals in building digital experience ecosystems, it comes with concerning tradeoffs, particularly if you employ Drupal as a standalone content service without a corresponding front end. In the fully decoupled case, abandoning the Twig-driven front end enables a better separation of concern and pipelined development, but it forces developers to be far more attentive to issues of accessibility and user experience.
Fully decoupling Drupal introduces considerable problems that should give pause to any stakeholder and demand frank assessment. For instance, an additional hosting stack introduces a second point of failure (though this is the case with each infrastructurally distinct consumer you add). Issues of security such as sanitization of user-generated content also deserve close examination. More relevantly for editors and administrators, key functions of Drupal that rely on its presentation layer such as contextual tools, layout and display management, previewable content workflows, and system notifications disappear except within the administrative interface, unless resurrected as replicas in the consumer application.
Progressive decoupling mitigates some of these concerns by providing some solutions; for instance, contextual tools, layout and display management, previewable content, and system notifications remain intact, though the "black box" problem is a source of concern for editors.
In other words, if you opt to decouple Drupal, whether fully or progressively, be ready to work with a highly competent development team with specialties in both Drupal and front-end technologies and to experiment with custom or contributed solutions as you progress with your decoupled Drupal architecture.