Decoupling with a Headless CMS

A headless content management system (headless CMS) exposes access to a collection of content (a content repository) via publicly available interfaces (APIs). This is an interesting option for organisations that have large amounts of content and want to use it in multiple channels.

Using a content repository and a JavaScript or a static site generator does not always bring any benefits, so it is worth considering whether you need traditional CMS functionalities like Layout Management and extensibility (via feedback forms, etc.) over a clean front end implementation.

Many of the tools on the market also remain tightly coupled with their front end libraries like jQuery and Backbone and fail to make a clean break on the backend between a content repository, a web framework and a content editing interface: Decoupling Content Management

Approaching the problem with a highly monolithic CMS with it's proprietary web framework makes it harder to switch between backends (content repository) and essentially couples you very tightly to that CMS, making the claims of freedom promised by the vendor very shaky indeed.

Common hurdles when decoupling with Headless CMS

Headless CMSes and Content APIs of all sorts are quite a hot topic nowadays. Despite them being used largely in the same ways as older content syndication protocols like ATOM and RSS, they being sold as the latest silver bullet.

It's important to understand that for complex sites and portals content is only a part of the functionality used in CMSes. Websites are a combination of content and functionality. In the simplest cases it's content, navigation and a feedback form. From there on it can grow into a fully personalised service platform like Trivago - a hotel reservation tool.

In these cases it often comes as a surprise that when decoupling a CMS (or using a Content API like Contentful) that you actually need quite a few functionalities from a content management system that has little to do with content creation:

  • Managing site navigation
  • Limiting access to content with permissions
  • Managing banners and layouts
  • Embedding feedback forms and other interactive elements

All of these some common things that people are often accustomed to having from a CMS. But if your platform only focuses on content, you will need to create these functions somehow. And this is not a minor implementation detail.

In addition you can easily couple yourself to a specific REST API implementation. Now there are interesting open standards such as GraphQL. It is worth to take a look at technologies like Falcor and GraphQL for Decoupling from a CMS.

One size does not fit all

The world of headless CMSes is not black and white. Probably the best solution is to merge bits and pieces of server side rendered templates as well as components rendered by the browser using a headless method.

A great example could be a sports news portal where news and listings are regular server rendered pages, but some dynamic parts like scoring functionalities or news tickers can be powered by a separate Universal JavaScript application. For news and live scoring in smartphone applications you could then utilise the same content in a different setting.

There are many tools that can function as a Headless CMS on the market and from the ones listed on this site at least the following have full capabilities of providing both reading and creation of content via a REST API interfaces using common JSON (JavaScript Object Notation format):

  • Drupal 8 is a partial modernisation of the legacy Drupal CMS.
  • eZ Platform is a completely rewritten CMS with 15 years of heritage.
  • Sulu is a new CMS that uses existing pieces from other pieces to focus on UX.

These tools and other Content APIs can be a perfect piece in creating a Content Management Platform for Data Journalism. For cloud deployment options it's advisable to make sure your selected CMS is ready for scaling on the cloud with Docker and other technologies.

Related links: