Putting the ‘Head’ back on headless CMS

There are times when technology advances and is adopted by developers but the applications and tools built are a step backwards for the end users.

Take electric cars, for example. When electric engines were first introduced to power vehicles, drivers couldn’t drive as fast or as far between re-fuelling. Today, electric-engine technology has finally caught up and is starting to surpass its gas-powered predecessor but the end users had to suffer through a period of adoption and transition.

A second example, and the focus of this article, is the ‘headless CMS‘ where development teams have opted to throw away a lot of the CMS platform features used by content editors in the favour of using their preferred technologies to build the solution.

Before we detail why this is happening and what CMS vendors are doing to address the problem, it is useful to understand the differences and respective advantages of a headless and non-headless approach.

A Headless CMS

In a headless CMS configuration, there is a technology separation between the platform presenting the content, for example a website or mobile app, and the platform which enables content management, storage and delivery.

The diagram below describes this model.

Some of the advantages of a Headless CMS include:

• Multi-channel support: Content as a service allows businesses to better manage content for multiple channels in one place.
• Scalability: Applications can scale more easily as they do not not have a dependency on the Content Management Platform’s technical infrastructure.
• Evolution: Applications can evolve more freely as their development opportunities are not constrained by the Content Management Platform.

A headless CMS can be contrasted against a ‘non-headless’ configuration where the platform additionally takes on the application and presentation concern and, due to the tight integration of these components, is able to offer content editors a host of useful features.

A Non-Headless Model

A non-headless CMS, also referred to as a Monolithic CMS or Coupled CMS, is a configuration where the platform presenting the content and the platform managing the content are one and the same.

The diagram below describes this configuration.

Some of the advantages of a Non-Headless CMS include:

• Fully supported and tested technology stack: Full stack CMSs solutions offer an out-of-the-box scalable technical solution which encompasses all application and content management components that are tried, tested and supported.
• Flexible, On-Page Editing experience: Since the presentation and management components are integrated into one platform, many CMS Platforms offer great tools for content editors such as the ability to create and edit content on the page as it would appear to the user. These editing tools allows editors to create rich and engaging experiences and see the end result before they hit publish.
• Personalisation. The integration of the Web Application components with the Content Management components have also allowed CMS vendors to create personalisation tools, allowing Editors to create page variations for different audience segments.
• MV testing and Tracking / Analytics. The integration of the Web Application components with the Content Management components have allowed CMS vendors to offer integrated MV testing and Tracking and Analytics solutions.

With all these advantages, why go headless?

Despite all of the advantages listed above, the headless approach is a popular choice in technology teams because it allows development teams to choose their own application platform and presentation layer technology.

One technology used to build web applications that is becoming widely adopted by the front-end development community is Single Page Applications. (SPAs).

SPAs are applications which run inside the browser and communicate back to the server via APIs. In SPAs, the browser works as an application run-time and handles all aspects of the application lifecycle, including: rendering, application logic, state and error management, and routing the user to different section of the application, all without having to have the browser post back to the server.

Today, front-end developers have a penchant for SPA frameworks because they have introduced an modern set of engineering patterns, practices and tooling into their discipline which promotes quality, efficiency and effectiveness.

The downside of this development goodness, in the case of headless CMSs and SPAs, is that the technology separation results in the loss of CMS features such as on-page editing and personalisation.

Because of this CMS Vendors have suffered because they now have vestigial features, and Content Editors have suffered because they cannot use these features that are integral in their jobs.

How are CMS vendors responding?

CMS Vendors are responding to this disconnect and finding ways of re-introducing the lost features if the platform is implemented in a headless configuration.

Most major CMS vendors are starting to offer different technology solutions. Sitecore have a new SDK called SiteCore JavaScript Services (or, slightly confusingly shortened to JSS). Adobe AEM supports headless configuration, although hasn’t yet published how it supports features such as On-Page edit, personalisation, tracking and analytics.

Another CMS Vendor tackling this problem is Episerver, an Enterprise CMS and Commerce vendor and partner at BIO.

BIO recently attended the Episerver Ascend Event, their annual user conference, to dig deeper into their approach.

The Episerver approach

The diagram below details the interactions between content editors, end users, the editor interface, the SPA and the Episerver Content Delivery API, and how features such as On-Page editing are supported.

Diagram Annotation

1. In this diagram, an application built using an SPA framework uses the Content Delivery API as a source of the content. The SPA could use any framework such as Angular, React or Vue.js.
2. When the end users use the application they are in fact using a SPA which pulls content from the content delivery API.
3. When Episerver edit mode is introduced it gets very interesting. Editors interact with edit mode using on page edit as they normally would and update content using the on page overlays (as shown above).
4. When content is updated it is saved down to the Episerver content repository and exposed via the content delivery API.
5. However the SPA updates to show the updated content when it has been changed by the editor in Episerver edit mode meaning the editor is editing a SPA using on page editing and previewing the result.
6. The ability for the SPA to update when content has been changed in the Episerver UI is facilitated by topics which are published to let the SPA know that content has been changed.

In summary

It is great to see CMS vendors such as Episerver starting to allow their content editing features to be included in headless architectures. These features are an important requirement for content editors and taking them away due to a technical evolution is a step backwards. Furthermore, preventing technology partners from developing using modern tools and frameworks is also not a viable option for any platform vendor.

What is clear is that SPA frameworks are here to stay and if CMS vendors are going to please both their end users (content editors) and developers, they need to provide elegant technical solutions that deliver on both fronts.