preston.so

Este artigo está também disponível em português. This article is also available in Portuguese.

Over the past six months, I’ve had the privilege of delivering keynotes at conferences in some of my favorite places both familiar and new, including Cluj-Napoca, Montréal, Pune, and Sofia. The central message I’ve endeavored to convey in those talks is that content management systems (CMS) should perhaps no longer be referred to as such, given the proliferation of focused solutions that occupy only one layer of the stack. In short, I argued that content management systems should now be referred to as content management stacks, an idea I expand upon in my previous post about what I call the distributed CMS.

Last month, I extended some of these thoughts in Nagoya and Tokyo at keynotes that covered the future of the content management system through the lens of both omnichannel digital experiences and wholesale evolution in the front-end development landscape. One statement in particular about a trait both monolithic and decoupled CMSs share garnered a few hushed whispers from the audience in Nagoya:

“The separation of concerns between data and presentation remains sacrosanct.”

After the talk concluded, I gave some thought to this statement and the reaction to it. Can we truly say that in the era of the headless CMS, the JAMstack, and serverless technologies that the separation of concerns in CMSs remains as unassailable as ever? Is it even valid to discuss a single separation of concerns when it comes to CMS architectures? In this blog post, I explore some of the ways in which we as developers and architects are straining the very notion of a single bifurcation between structured data and its presentation.

The separation of concerns in monolithic CMSs

Monolithic CMSs like Drupal and WordPress have long had internal separations of concerns, despite the monolithic approach their architectures take out of historical necessity. In Drupal, for instance, there is a clear division between the database all Drupal sites depend on and the final rendered output, straddled by the database abstraction layer and rendering processes. But in monolithic CMSs, the separation of concerns has always been a theoretical consideration rather than one obligated by other prerogatives.

Towards the end of what I call the second wave of the CMS, which introduced a range of unprecedented innovations for content editors, the already thin line between data and presentation was further blurred thanks to the development of contextual features such as Drupal’s Quick Edit module (also known as in-place editing), Contextual Links module, and others. In these implementations, complex user interfaces interacting with Drupal’s configuration and content are exposed not only on the administrative back end into which most content editors input content, but also on an authenticated front-end layer of the CMS that interpolates said interfaces into the content.

While this had the immediate benefit of permitting editors to make immediate changes to their content without having to navigate all the way back to the more staid administrative interface, it also had the consequence of presenting challenges with regard to the separation of concerns, and this was a key topic of discussion during the debate surrounding the introduction of Spark initiative features into Drupal core in 2012 and 2013. In short, features like in-place editing and contextual links began the straddling of the separation of concerns that is now commonplace.

Proudly rendered elsewhere: Rendering in new settings

Readers who are familiar with my previous talks and the initial chapters of my book Decoupled Drupal in Practice (Apress, 2018) will recognize my frequent assertion that the current upheaval in the CMS landscape is due to two distinct centrifugal forces that have shaken the monolith to its core.

From one-to-one to one-to-many

First, the channel explosion and the proliferation of new channels for content has led directly to a one-to-many relationship between CMSs and interfaces (whether we mean conversational, voice, virtual or augmented reality, or others). No longer is there a single web-based front end tightly coupled to a CMS in an inseparable monolith.

Second, the same one-to-many relationship is increasingly emerging in the JavaScript world as well. While in the initial days of headless CMS architectures and decoupled Drupal we saw primarily single JavaScript front ends atop CMSs, the notion of the API as a consumable data layer for a variety of JavaScript front ends has piqued the interest of large enterprises and other organizations with many web properties. In fact, in one meeting with an enterprise Drupal user last month, I learned that they were leveraging not only Drupal’s native front end but also a variety of other JavaScript-driven front ends, all with one crucial characteristic—a shared design language unifying the appearance of every site irrespective of its technical provenance in terms of framework choice.

In short, many developers at large organizations leveraging headless CMSs have increasingly made the transition to using a variety of JavaScript technologies, not just one, to power their various front-end experiences. From a logistical and operational standpoint, this calculus makes perfect sense, not only to keep teams specializing in diverse technologies engaged but also to diversify the internal front-end landscape and hedge against inevitable disruption in the front end.

JavaScript-driven rendering is encroaching on traditional server-side rendering

In much of my previous content about decoupled Drupal, I’ve long waxed poetic about the benefits and advantages that JavaScript-driven rendering provides thanks to the promulgation of universal JavaScript, which ushered in an unprecedented era of innovation in front-end development. However, it is also true that JavaScript rendering is increasingly encroaching on traditional surface area that traditional monolithic CMSs have occupied: the rendering process.

This sets up a conflict when it comes to the separation of concerns. When progressive decoupling became a topic of interest in the Drupal community, the chief critique was of the notion that two wildly different rendering approaches would need to meld together somehow on a single page. And monolithic CMS ecosystems have not entirely solved the issue surrounding how to integrate gracefully with the rendering that JavaScript now offers, technologies like Twig.js notwithstanding.

I often hear engineers referring to JavaScript rendering as client-side rendering, but this is a misnomer that has the potential to obfuscate the ramifications of universal JavaScript and server-side rendering in JavaScript on monolithic CMSs and their futures. In other words, there is an emerging battle that is primed to explode into an all-out war—or disruptive collision—between JavaScript server-side rendering and traditional CMS server-side rendering like Drupal’s render pipeline. While within the JavaScript community it’s generally seen as a foregone conclusion that JavaScript rendering will rule the world, the new challenge for traditional CMSs that are now API-enabled is how to grapple with, integrate with, or even subsume JavaScript rendering into their own rendering processes.

APIs as another data layer

One of the reasons why the separation of concerns is such a complicated consideration for formerly monolithic CMSs that are now API-enabled is the fact that APIs introduce considerable complexity to separation-of-concerns questions. For instance, Drupal now has JSON:API, GraphQL, and a CouchDB implementation available in its API-first ecosystem, but these APIs can be considered data in their own right, as reflected in the hand-wringing in the community over how to expose formatted HTML and other presentationally rich information through APIs that are also structured data in their own right.

How similar should the data transmitted through an API be to the data available in foundational databases? It’s a question that has seen a variety of answers. The initial REST API implementation in Drupal, for instance, hewed closely to the precise structure of data housed in the database, while the JSON:API and GraphQL implementations in Drupal needed to recast data due to the unique demands of the specifications to which they adhered.

Editorial and administrative implications

In an early chapter of Decoupled Drupal in Practice, I describe a phenomenon I saw in several proofs of concept and experiments as headless CMS concepts began to surge not only among formerly monolithic CMSs but also among upstarts like Contentful, Prismic, and others: pseudo-decoupling. In pseudo-decoupling, a JavaScript front end responsible for rendering CMS data also permits presentational information to leak through such as layout information provided directly to the API, an approach that clearly flouts the traditional separation of concerns in the CMS.

When we introduce still other functionality that creates shared information about presentation between a JavaScript front end and the native front end of a now API-enabled traditional CMS, it can lead to unintended consequences. There is no significant distance between, on one end, the notion of a JavaScript front end relying on API data not only for content but also for layout and, on the other, the concept of a contextual feature that introduces layout manipulation capabilities to the same front end. If two editors make a modification on the contextual interface and on the administrative back end simultaneously, race conditions could surface.

Stress tests for the separation of concerns

As CMSs continue to innovate novel ways for editors to impact the presentation of content on front ends rendered elsewhere, so as to match the previous manipulability available to editors in monolithic CMSs, there are several emerging ways in which we are straining the traditional separation of concerns in the CMS. The headless CMS has overturned so many assumptions that there is now substantial unexplored territory.

Drupal: Paragraphs as presentation and data

One of the more fascinating modules to become popular among Drupal developers is the Paragraphs module. For those unfamiliar with Drupal, the Paragraphs module makes arbitrary listings of content possible on an entity such that they can be ordered on a page in a particular sequence. Conceptually, this is similar to the Nodequeue module commonly leveraged in previous Drupal versions.

Over the past year, I have seen significant growth in the employment of Paragraphs as a means for editors to influence how content is presented on decoupled front ends implemented in Gatsby, Vue, and others. It is just one example of how concerns that were primarily the domain of presentation in monolithic CMSs are now leaking into the bridges between data and presentation. In the Paragraphs case, a highly limited quantity of information about presentation is now shared with the client, but the developer experience can admittedly be quite variable. The jury seems to be out on any potential architectural ramifications, and Paragraphs should be used as part of a one-way rather than bidirectional approach to the administration of sequential content.

Storybook: Framework-agnostic components

Another fascinating open-source project, Storybook, aims to provide user interface components that are agnostic to three of the most widely used JavaScript technologies in existence today: Angular, React, and Vue. By doing so, Storybook has made a notable entry into the liminal space between data and presentation, a gulf opened partially by the expansion of JAMstack and JavaScript front ends in the CMS space.

While technology-agnostic components are nothing new (cf. Web Components), the notion that they can resolve some of the issues around the traditional separation of concerns in CMSs certainly is. I can see abstractions similar to Storybook surfacing in the near future that not only enable the pairing of data with components adhering to a design system but that also enable a rich integration with a CMS for editors to preview their data in components irrespective of the eventual rendering layer chosen. This would be a compelling solution for enterprises with a wide range of JavaScript technologies in use but no hope of ever reconciling the divergent choices of frameworks.

Three choices for traditional CMSs

As for traditional CMSs, the emerging complexities introduced by unexpected turns in how we approach the historical separation of concerns mean that CMSs have three choices when it comes to how they proceed in the new headless CMS landscape, and possibly others too. As we have seen in countless headless CMS products, maintaining a variety of software development kits (SDKs) like Drupal’s Waterwheel ecosystem and integration guides for every possible JavaScript technology is a demanding exercise.

Specialize in the API-first monolith

Some traditional content management systems have increasingly leaned away from the problems presented by headless CMSs whether due to the potential for abandonment of their core user base or due to the dizzying pace of innovation in front-end development today. And some of these projects are also adopting novel ways of providing a monolithic architecture that also enables content consumption externally through APIs (see Dries Buytaert’s “Drupal is API-first, not API-only” for a compelling defense of this approach with contributions from this author), particularly through editorial interfaces that employ a headless approach to enable more interactive editorial experiences while all rendering of the actual front end occurs server-side and remains within the confines of the CMS itself, thereby keeping the end user experience the same.

For instance, while Drupal previously has been on the forefront of newfangled ideas concerning headless CMS architectures, even disseminating the notion of progressive decoupling to encourage greater adoption, in more recent years it has pulled back due to the need to honor site building use cases in addition to the demands of developers. Over the past year, Drupal has refocused its attention on layout manipulation in its core CMS, with Acquia acquiring Cohesion DX8, which leverages Angular. Meanwhile, the Drupal community has adopted React for use on a decoupled editorial interface but not elsewhere in its rendering layer, in a fashion similar to WordPress’s adoption of React for Gutenberg.

Adopt a single front-end technology

Another option that CMSs have is to enforce an adoption of a single front-end technology for use with the CMS’s APIs. Historically, CMSs have eagerly adopted libraries and frameworks to enable richer interactions and the issuance of Ajax requests. Drupal was famously the first major CMS to adopt jQuery, and this spirit of experimentation with JavaScript continued with later incorporations of Underscore and Backbone.js. However, many CMSs have rightfully been shy to declare any dependency on the relatively transient technologies of today that often not only have limited longevity but also threaten the viability of the CMS’s own native front end.

For the vast majority of CMSs, the decision to adopt a single front-end technology or not is a calculation that could have outsized ramifications for years, even decades, to come. Selecting the wrong technology is a potential recipe for disaster. For this reason, some CMSs are writing their own frameworks that integrate with their native APIs at a level of seamlessness that is impossible for frameworks that are not under the same community’s or organization’s control. Consider the case of Tome, for instance, a static site generator that integrates tightly with Drupal’s render pipeline, or Oracle JET, a framework for building user interfaces developed by Oracle (where your correspondent is now employed, as a disclaimer) and used widely internally.

Build bridges of abstraction between data and presentation

In my perspective, neither of these approaches will be tenable for very long. While remaining an agnostic headless CMS irrespective of evolution on the front end is a viable proposition, many CMSs, particularly those that have lengthy histories, must contend with naysayers who question the value of a CMS whose role has been reduced to that of an API-enabled content repository, without all the contextual and administrative bells and whistles that editors have become familiar with, such as layout management. After all, when a CMS becomes a dry content store, why use it at all?

Similarly, I don’t believe that selecting or maintaining a fully-fledged JavaScript framework or the like is a viable option for the vast majority of CMS makers. Though React remains far and away the most popular, one of the unavoidable laws of software development is that frameworks come and go with the ebb and flow of developer expectations. By the same token, maintaining your own framework can quickly become a nightmare if the development team is inadequately resourced or falls even the slightest bit behind the accelerating evolution in JavaScript and front-end development.

For this reason, I believe that we will begin to see more efforts at building bridges to patch the widening gap between the modus operandi of traditional CMSs and their front-end upstart counterparts. It’s likely this will come in the form of increasingly agnostic abstractions that aim to link dry components without implementation detail to data requirements from the CMS. GraphQL, Gatsby, Storybook, and others are just the beginning in what is sure to be an important inflection point in the storied history of the CMS.

Conclusion

In software architectures, the separation of concerns is one of the most essential principles, and respect for it remains a best practice. As new architectural paradigms evolve, however, the place where the separation of concerns occurs merely migrates to a new place, much like fault lines over time that straddle geologic strata. In monolithic content management systems and their architectures, the data–render divide (formerly referred to, now with less accuracy, as the client–server divide) has long served as the nexus of interactions between structured data and presentation. With the advent of decoupled and headless CMS architectures, where the separation of concerns is increasingly prone to blurring, where is the line situated now?

It is useful to consider the API all of our content ecosystem’s consumers depend on to be the single source of truth for data and thus the place where the separation of concerns is located, but this ignores the slew of ways in which back-end architects are introducing editorially manipulated presentational information for consumption by front-end developers. Besides the inevitable contention that this reduces the flexibility allowed front-end developers, it also introduces potentially destructive ramifications for the future.

Fortunately, the API may not be the only bridge straddling the separation of concerns in not very much time. The story of how editors and developers will interact in the headless CMS landscape is still being written, but we’re certain to find clues in the no man’s land in between, where the tensions of the separation of concerns among personas can be felt, but less readily seen.