preston.so

Reprinted from the Acquia Developer Center with permission from DC Denison (Senior Editor, Acquia).

With the advent of web services in Drupal 8 core, decoupling Drupal — namely, using Drupal as a content repository to expose data for retrieval and manipulation by other applications — has never been easier. Now, with the REST module in core, you can transform Drupal into a data service without custom code or substantial configuration. But is it a good idea? What are some of the considerations you should scrutinize when opting for a fully decoupled project?

Decoupling Drupal is now on most of the Drupal universe’s radar, and Drupal project lead Dries Buytaert also has his own recommendations when it comes to decoupling. Fully decoupling Drupal involves a complete separation between Drupal’s front end and back end, in which the Twig theme layer is replaced with a different front end entirely. Examples include native mobile or desktop applications, JavaScript single-page applications, other server-side applications, or even Internet of Things (IoT) applications.

Typically, these applications communicate with Drupal using a RESTful API, which serves as the middle layer between the front end and back end. In Drupal, a RESTful API exposes resources as JSON or XML, which can be queried or modified using the HTTP methods which underlie the web as it exists today, such as GET, POST, PATCH, and DELETE.

In this blog post, I’ll walk through some of the implications of fully decoupling Drupal — in short, using Drupal solely as a back end and not as a front end. While a fully decoupled Drupal implementation comes with several big benefits, the risks can quickly render a project prohibitively expensive. In short, if you fully decouple Drupal, you have to be prepared to replace — or otherwise abandon some of the features that we have long taken for granted.

Rewards of fully decoupling Drupal

The advantages of fully decoupled Drupal implementations are numerous. Employing Drupal solely as a data service is particularly compelling if you have a team that specializes in a JavaScript framework, or other front-end technologies besides Drupal.

Separation of concerns

One of the fundamental tenets of web development is the notion of separation of concerns. Structured content and its delivery is the skeleton of Drupal — the structure — while templates and corresponding logic comprise its cosmetic appearance — the presentation.

By provisioning data to the front end solely in JSON or XML, all aesthetic considerations which may have decorated the data in a monolithic implementation are moot. In fully decoupled Drupal, the front end alone controls the presentation of the data. Compelling exceptions such as RESTful Panels are available but challenge the way we conceptualize the separation of concerns between structure and presentation.

Differentiated development velocities

If you have a team split between developers with front-end expertise and others who are experienced Drupal developers, you may have encountered issues in your project’s progress due to the lack of intelligibility between both skill sets. For instance, while Ember developers are well-versed in Handlebars, they may balk at a Twig template in Drupal.

Fully decoupling Drupal allows both teams to pursue their own velocities. Front-end developers are no longer hamstrung by the limitations of the Drupal theme layer, and they are free to exert control over all markup and rendering. Similarly, Drupal developers need not worry about the nuances of the front end, instead focusing their attention on constructing a robust RESTful API.

Content syndication and application ecosystems

Last but not least, the idea of “write once, publish everywhere” is quickly gaining momentum in content delivery circles, particularly when it comes to multichannel publishing. As publishers and content providers increasingly leverage diverse means to export their content and data to a bevy of touchpoints, Drupal can serve as the centerpiece of a constellation of applications, each of which ingest data emanating from a single source.

It is crucial to note here that Drupal need not be fully decoupled to enable content syndication as part of an application ecosystem. In fact, many traditionally monolithic Drupal sites export data for ingestion by fully decoupled applications. In this paradigm, Drupal preserves its end-to-end contiguity and serves as both a public-facing Drupal site and a centralized data service for decoupled applications. Indeed, this is the architecture Dries recommends explicitly for a set of applications requiring data from a Drupal repository.

Risks of fully decoupling Drupal

If you choose to use Drupal solely as a data service, however, without leveraging any of its front-end features, your architecture may run into more risks, and you will either need to rebuild critical functions Drupal performs or jettison them altogether.

Additional point of failure

Traditionally, monolithic Drupal architectures are hosted on LAMP stacks, which are commonplace on the web. However, fully decoupled applications written in JavaScript (and which can be compiled to native applications) require Node.js-based stacks, such as MEAN (MongoDB, Express, Angular, Node.js) or MERN (React in lieu of Angular). Still other cloud platforms may be required for native mobile or IOT applications.

For this reason, introducing another hosting stack into your infrastructure may not be advisable for companies with more modest means. But there is another important reason for pause: Another stack represents an additional point of failure. If the Drupal site containing your REST API fails, the data shown by your application will be stale or nonexistent. Similarly, if your applications go offline, your data is now completely inaccessible, since Drupal has no front end on which to display its content, unless the central repository is a public-facing site.

Security and input sanitization

Though most notable JavaScript frameworks and application frameworks have mechanisms to protect against cross-site scripting attacks, such as input sanitization, fully decoupling Drupal requires you to consider the security implications of your architecture carefully. For instance, Drupal contains text sanitization and form validation out of the box for all fields, but leveraging this feature requires a coupled implementation.

This is a significant risk, particularly if you are creating your own homegrown framework or “vanilla” approach which does not employ any existing tools. The security of user inputs becomes a significant concern at this point. Rather than letting Drupal do the heavy lifting, research will be required to determine the right course of action to ensure the security of your applications and their users.

Contextualized editing and administration

Among Drupal 8’s most compelling features are contextualized administration tools such as in-place editing (Quick Edit) and adjacent menus for configuration (Contextual Links, long a Drupal fixture). In an in-preview context, these administrative interfaces allow editors and site builders to make adjustments to content or configuration on the fly while the result is in view.

Decoupling Drupal’s front end means that these contextualized tools have no place to live, unless they are rebuilt from scratch on the decoupled front end. Using a distinct front end from Drupal’s own transfers the responsibility to the front-end developer, who must either provide replicas of those tools or acknowledge this detriment to the editorial experience.

Layout and display management

Drupal 8’s core and contributed modules for layout and display management offer a rich array of features to control how content is variably displayed (Display Suite), or how “panes” of content should be structured into a layout (Panels). These modules are tightly coupled to Drupal’s appearance layer, and as such require a high degree of control over Drupal’s markup.

Without available features such as Panels, layout management suddenly becomes a matter for the developer, not for the site assembler. This presents difficulties for marketing teams with little development experience. If you wish to continue empowering an editorial team to make modifications to layout and not solely content, you will need to either utilize Drupal’s existing patterns, reconstruct layout management as a feature in your framework of choice, or export layout configuration details using a module like RESTful Panels.

Previewable content workflow

One of the central pillars underpinning any robust CMS is the concept of content workflow, in which content states such as drafts can be easily previewed without incurring the danger of their accidentally being posted. This is particularly important in the case of embargoed content, in which prematurely published content can damage a business’s reputation and its connections.

Without Drupal’s ability to display previews of content in their workflow states, the notion of previewable content workflow from the editorial standpoint becomes much more difficult. Some of the roundabout solutions include setting up an additional staging environment inaccessible to the public for editorial previews or extending your REST API to provide previewable content through means such as additional authentication or unique query parameters.

System notifications

One of the central features of Drupal is its notification system, which alerts you about any issues in an installation of Drupal. These can include severe errors which require your immediate attention. Though a REST resource is available in Drupal to retrieve watchdog logs, these are only some of the possible errors that administrators should be aware of. Drupal system messages as shown at the top of rendered pages are unavailable in a fully decoupled environment.

In short, in order to maintain full awareness of potential issues in Drupal that may affect the provisioning of data for your applications, you will need to scrutinize system messages within the Drupal administrative interface, as these will be unavailable in a JavaScript or native application framework without substantial custom code.

Improved performance

Drupal 8 core now includes cache tags, or cacheability metadata, which allow you to declare dependencies on data managed by Drupal and allow for cache invalidation of items that rely on granular content contained therein. This is what enables BigPipe, which provides progressive loads of pages based on the cacheability of a page’s component, thus abbreviating time to first paint.

These capabilities open the door to significantly improved performance when it comes to Drupal’s page loads. As such, the argument against using end-to-end Drupal for reasons of page load performance are less convincing, and this form of progressive loading based on varied cacheability cannot be leveraged as a feature in a fully decoupled implementation.

Accessibility and user experience

Last but not least, accessible markup and user experience are key considerations for any Drupal site. For instance, Drupal has ARIA roles and other techniques to provide for users of assistive technologies such as screen readers. In addition, Drupal’s strong focus on usability ensures that all user interfaces built on Drupal follow certain standards.

Markup and user experience are two elements that require a complete reinvention in the fully decoupled use case, because those applications no longer enjoy access to Drupal’s construction of markup or its available slate of core interface components and interactions. As a result, the onus is on the front-end developer to become the “markup guru” and craft a compelling user experience without the aid of Drupal.

Conclusion

While decoupled Drupal is a compelling and eminently useful solution for facilitating application ecosystems, it comes with significant trade-offs if you opt to use Drupal solely as a data service without a coupled front end. Fully decoupling Drupal without the Twig-driven front end means that you can enable better separation of concerns between structure and presentation, as well as differentiated development velocities between front-end and back-end teams.

Nonetheless, decoupled Drupal — and jettisoning the Drupal front end — translates into issues that you should be prepared to address in a client project or in your own builds. For instance, hosting an additional application requires an additional stack beyond the traditional LAMP stack, thereby introducing another potential point of failure. Moreover, you will need to rely on your own or a framework’s methods for cross-site scripting protection and input sanitization. More relevant to the editor, administrator, and end user experience, crucial features such as contextualized administration, layout and display management, a previewable content workflow, in-page system notifications, improved performance, and accessible markup and user experience — they will all have to be provided by you or the front-end framework you choose.

If you are interested in pursuing a fully decoupled architecture because of the user experience benefits that accompany it, there are alternatives, the most prominent of which is progressive decoupling, in which JavaScript application components are interpolated into a page output rendered by Drupal. With the help of an expanding ecosystem around progressive decoupling, you can achieve your user experience goals without abandoning features that are hallmarks of Drupal.

In short, if you decide to decouple Drupal, you should be prepared to engage a highly competent front-end development team and experiment with your own solutions as you explore this exciting new architectural paradigm.