preston.so

In the ten months since I wrote my description of the distributed content management system (CMS) and how it represents the fourth wave of the CMS, the response has been nothing short of spectacular. I’ve heard from many developers, designers, CMS architects, and content strategists about how they have noticed the same paradigm shifts occurring in their own organizations, particularly as the explosion in innovation in front-end development and new third-party services for websites continues apace.

In the time since, I’ve retreated somewhat from some of the more polarizing components of the argument, particularly the notion that distributed CMS architectures intrinsically render marketing teams’ and content editors’ lives easier in addition to developers’. As I have more recently contended, while current CMS trends certainly lend a great degree of privilege to developers who have long chafed at woefully obsolete theming and templating experiences, they have left marketing teams and editorial teams far behind in a shattering of the grand compromise that characterized the first two waves of the CMS.

My view on the distributed CMS as a market trend has gathered more nuance over the ensuing months as I have shared my perspective on shifts in the separation of concerns in CMS, the emerging second CMS war, hierarchies of needs in digital experience management, and preview beyond the static web. Now, it’s time to revisit the topic of the distributed CMS in the context of other trends that have been surfacing contemporaneously, namely microfrontends.

Ashish Thakur recently asked me on Twitter whether my conception of the distributed CMS bears any relevance to the highly controversial—but admittedly fascinating—article by Cam Jackson last year articulating a new approach to front-end development named microfrontends. Intended to be roughly analogous with back-end microservices but from the front-end standpoint, Jackson defines microfrontends as “an architectural style where independently deliverable frontend [sic] applications are composed into a greater whole.”

From a high level, morphologically speaking, my description of the distributed CMS does resemble somewhat the approach suggested by Jackson, but that is where the similarities end. While distributed CMS implementations can certainly include presentation layers composed of multiple front-end applications, this is by no means the only way to leverage the benefits of distributed CMS techniques. After all, as long as a third-party service—the primary analogue to Jackson’s “microfrontend”—has an API that allows for programmatic access to that service’s capabilities, the heavy-duty infrastructural needs Jackson describes are not at all necessary.

And even in the case where such services require you to employ their lightweight library to outline the page component where that service’s functionality will be presented to the user, it is very seldom the case that the code constituting the library dependency and any additional configuration or logic is large enough to come close to approaching the oversaturation of monolithic front-end applications that microfrontends are intended to address.

In this article, I revisit the topic of distributed CMS explicitly for the first time since my initial treatment of it last year by approaching it from the angle of microfrontends. In short, whereas microfrontends involve distinct application codebases combined together to form another cohesive larger application, the distributed CMS encompasses this trend but also those that involve mere API-driven or library-based front-end services. In other words, microfrontends are one possible way to leverage distributed CMS ideas, but they are by no means the only one.

What is the distributed CMS?

As I’ve written previously, the distributed CMS is the logical next step from the headless and decoupled CMS paradigms that have surfaced over the past decade, including decoupled Drupal. In lieu of merely benefiting from interchangeable presentation layers, in which developers can substitute a different JavaScript framework easily for another without impacting the ways in which data is presented to the front end, the distributed CMS trafficks in interchangeable services within the same presentation layer.

Consider, for instance, the fact that many CMS ecosystems have long been stymied by the problem of plugin maintainability when it comes to common website needs such as e-commerce, search, form handling, and analytics. Today, however, a slew of new startups is emerging that handles each of these concerns outside the confines of CMS ecosystems. In the past, whereas a developer employing Drupal or WordPress would be limited solely to the modules and plugins available in those communities, the client-agnostic stance of hyped ventures like Algolia, Snipcart, Typeform, and Segment lend themselves to developers venturing out of their comfort zones to experiment with new approaches.

In short, the distributed CMS extends the interchangeability of presentation layers (as engineering teams encounter better developer experiences, they can easily switch Angular out for Vue, for instance) to interchangeability of services within the presentation layer itself. By utilizing a JavaScript framework and relying on APIs for structured data, developers can easily interpolate Algolia-driven or Snipcart-driven components into their applications and substitute them as new vendors emerge. This is something that is simply impossible in the legacy CMS landscape, where a lack of committed maintainers stymies the adaptability of CMS implementations. Moreover, the distributed CMS allows for auxiliary functions formerly under the auspices of the monolithic CMS to be handled more flexibly by a variety of services working in concert.

In my previous treatment of the subject, I also argued that the distributed CMS is intrinsically better for marketing and editorial teams. While it is true that marketing and content teams can benefit immensely from the more contemporary user experiences represented by third-party paid services, the vast majority of these services require developers to facilitate the initial setup of said services. This is a regression from the marketer and editor experience standpoint away from previous iterations of the CMS in which so-called “site builders” could easily install and disable plugins to add and remove functionality. Because of the distribution of CMS architectures, developers are necessarily responsible for gluing these disparate architectural elements together.

Microfrontends involve composition of discrete applications

The core idea behind microfrontends centers around the notion that a microservices model is appropriate for front-end developers, a notion shared with the distributed CMS but rendered in a much narrower way in microfrontends. In short, microfrontends are entire front-end applications that are later composed to form a single combined application before being served to the user’s browsers. Jackson outlines a variety of means through which these applications can be integrated together.

The initial article expounding upon microfrontends as a paradigm attracted significant interest and criticism from the front-end development community, and I recall the discourse surrounding Jackson’s explanation when it first emerged. I agree with critics who contend that microfrontends appears to be an approach that favors developers’ experiences working on projects over issues such as maintainability and performance. Nonetheless, I understand the rationales behind the adoption of microfrontends, but I struggle to see how they can apply to more than a slim minority of JavaScript implementations that require the coalescence of separately owned codebases into a cohesive whole.

One of the key pieces of terminology adopted by proponents of microfrontends from the microservices world is orchestration. In order to juggle a variety of applications and compose them into a single container application, careful consideration of orchestration and the underlying infrastructure supporting that orchestration is required. Jackson himself calls out these in enumerating the disadvantages of microfrontends when it comes to differences between environments and operational complexity when it comes to governance, the potential for colossal payload sizes notwithstanding.

The distributed CMS involves services that may or may not be applications

This brings me to the crucial distinction I must make between Jackson’s conception of microfrontends and my own promulgation of the distributed CMS. Whereas microfrontends necessitate orchestration and significant investment in infrastructure, the distributed CMS instead confers upon developers a spectrum of possibilities according to the flexibility afforded them by third-party service providers such as Segment and Typeform. The only prerequisite is the combination of such services with structured content originating from an API-enabled CMS such as Oracle Content and Experience (OCE) or decoupled Drupal.

Developers’ integrations with these interchangeable services can vary from minimal interference, in which developers issue API queries and handle responses within the same framework where other business logic is housed, to full adoption of microfrontends and all of the promises it makes around code manageability. And between these two extremes, where services provide libraries that must be incorporated into applications of varied technologies, Algolia being a case in point, there is no need to maintain that integration as a separate application.

To illustrate this in a clearer way, consider the fact that in-page services in distributed CMS implementations are just that: in the page. There is no significant difference from the standpoint of the distributed CMS between application components issuing queries to third-party APIs, components that leverage external JavaScript provided by those third-party services, or components that are microfrontends and therefore entire applications in their own right.

A question of infrastructure versus architecture

The diagram above illustrates some of the key distinctions between microfrontend approaches and distributed CMS architectures and how distributed CMS implementations open the door to a more diverse range of outcomes than would be possible when leveraging solely microfrontends as a paradigm.

Perhaps the most succinct way to differentiate microfrontends from distributed CMS implementations is their relative emphasis on distinct concerns in the software architect’s mind. Whereas microfrontends lean on increased infrastructural requirements to handle orchestration needs, the distributed CMS is primarily about architectural considerations and decentralizing concerns away from the CMS monolith. This highlights one of the most important differences between the two trends: in many ways, microfrontends exhibit greater centralization due to the need for an orchestration service.

In short, whereas microfrontends obligate the addition of infrastructural services, distributed CMS implementations instead obligate adjustments to architectural concerns such as APIs and libraries to depend on. And the manner in which microfrontends require a central composition step as the last phase before deployment to production is anathema to developers and architects seeking a more distributed approach to web development that truly approximates the ideals of decoupling the CMS in the first place.

Conclusion

Ultimately, the choice of approaches when it comes to infrastructure and architecture is reliant on a bevy of considerations and thought processes that are unique to each engineering team’s needs.

Microfrontends remain a relatively untested idea at scale and have reckoned with significant controversy and criticism in the front-end developer community. I have a more nuanced take that dispenses with the prescriptivist critiques and instead focuses on use cases and needs. Though in my view they are relatively few and may be symptomatic of greater organizational issues, I can certainly envision use cases that require the composition of applications into a greater whole that Cam Jackson’s description touts. Nonetheless, I believe that adhering to a less rigid architectural approach allows for a richer array of developer experiences as seen in many distributed CMS implementations in production.

With the help of Gatsby and other JAMstack technologies, the distributed CMS is easily implementable in production, and in fact, there are many organizations already employing this model to power their own web experiences. The distributed CMS as a concept merely captures a trend that has progressed over the past several years and is proven to facilitate improved developer experiences, as directly evidenced by the runaway adoption of such architectures that aim to distribute and decentralize the CMS.

In the end, while microfrontends are one compelling way to access the advantages of the distributed CMS, they are by no means the only one.