How the separation of concerns in content management systems is shiftingJanuary 14, 2020
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.
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
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
Three choices for traditional CMSs
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
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?
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.
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.