Advantages and Disadvantages of Decoupled Drupal

Editor’s note: The following is excerpted from Preston So’s new book "Decoupled Drupal in Practice," now available for preorder.

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

While there are many advantages of decoupling Drupal in your own implementation, there are a few that are particularly valuable to marketing teams, to developers, and to businesses: namely content syndication ("write once, publish everywhere"), an architectural separation of concerns (structured data as distinct from presentation), and pipelined development. Employing Drupal as a web service provider is particularly true if you have a team that specializes in JavaScript or in other front-end technologies besides 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.

Content syndication

"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.

The question of user experience in this case is closely intertwined with the issues surrounding the front-end developer experience (see next section). For instance, an interactive application requiring frequent re-renderings of content may not be as effective in Drupal as in a JavaScript framework better oriented to the task. Nevertheless, for consumer applications built for mobile audiences, the user experience must be well-suited to the task, and Drupal's responsive design may not be sufficient to provide a user-centered experience.

In progressively decoupled Drupal, a JavaScript framework is employed to enhance the existing user experience provided by Drupal, whether that means to replace as much of it as possible or to add interactivity to a section of a single page. In this way, a more user-centered experience can be applied selectively to an existing Drupal front end in an incremental fashion.

Front-End Developer Experience

For many front-end developers, especially those well-versed in JavaScript, the Twig-driven front end of Drupal may be complex and distinct from the paradigms they have worked with in the past. Some teams are made up of primarily JavaScript developers for whom modern front-end development requires ample use of NPM and other JavaScript development tools. In addition, Twig and Drupal's AJAX framework are ill-suited for highly interactive applications that may be requested by business stakeholders.

Decoupling Drupal, whether fully or progressively, offers developer teams the ability to apply specialized knowledge in a differentiated fashion to desired functionality. For instance, the use of a JavaScript framework that a developer team is intimately familiar with can accelerate development on a progressively decoupled project. By the same token, a fully decoupled Drupal implementation with a JavaScript consumer opens access to a JavaScript framework's features.

This is particularly true given the immense advancement that JavaScript as a language has seen in recent years and its favorable positioning for use in interactive client-side settings. New features in ES6, the current version of JavaScript seeing widening browser support, such as arrow functions, destructured assignment, the spread operator, and classes, among others, offer a much more pleasant experience for developers than ever before.

Pipelined Development

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.

Conclusion

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

Typically, monolithic Drupal implementations are hosted on LAMP (Linux, Apache, MySQL, PHP) stacks, which are ubiquitous on today's web. On the other hand, JavaScript consumer applications that are clients in a fully decoupled architecture obligate the use of Node.js stacks like MERN (MongoDB, Express, React, Node.js) or MEAN (Angular in lieu of React). Other solutions entirely may be necessary for native mobile or IoT applications which have different demands.

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

Whereas the vast majority of modern JavaScript and application frameworks contain means to combat cross-site scripting attacks, including measures like input sanitization, both fully decoupled and progressively decoupled Drupal obligate that you carefully scrutinize the security implications of your architecture. For example, even though Drupal offers form validation and text sanitization out of the box for all form fields, this is only available in a monolithic architecture.

If you or your organization opts to utilize a bespoke framework—or "vanilla" JavaScript without the aid of a framework—the security of user-generated input becomes a potentially massive risk, a hazard that warrants strong emphasis here. Instead of allowing Drupal to do the heavy lifting, your homegrown approach will require ample research to evaluate whether you have taken satisfactory steps to ensure the security of users, the consumer applications, and ultimately the entire architecture.

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.

System Notifications

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.

Such capabilities give Drupal the means to achieve significant performance improvements during the page load. Sometimes, BigPipe can alleviate developers' concerns about monolithic Drupal performance by benefiting from a similar page load performance as that expected in JavaScript applications. This type of progressive loading dependent on cacheability metadata is not available to developers of fully decoupled implementations, but progressively decoupled builds can in certain cases leverage the feature. Of course, for those who lack pre-existing Drupal sites or are less accustomed to Drupal's feature set, this disadvantage may be less relevant.

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.

In the fully decoupled and progressively decoupled setting, when it comes to JavaScript applications, markup and user experience require considerable more thought, because Drupal no longer provides readymade front-end code or a roster of core interface components and interactions to rely on. This results in the front-end developer needing to craft a suitable user experience and robust accessibility without the aid of Drupal. Fortunately, JavaScript frameworks have made significant strides in accessible markup in recent years.

Conclusion

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.

For more insights about decoupled Drupal, preorder your copy of "Decoupled Drupal in Practice."