The What and Why of Headless CMS

Headless content management systems are what everyone seems to be talking about these days. This article does an analysis on the need for such CMS systems and when must they be applied.

The history of CMS

CMS is short for Content Management System, a software application that allows for websites and their content to be managed easily. The main idea behind a CMS is to separate the content layer from the presentation layer.

Traditional website visitors have started to access website via various mediums for example a smartphone. This has created a new challenge for the content authors as they now have to create and manage content across various channels. This problem can be solved by adopting a headless CMS approach.

What is a headless CMS?

A headless content management system is a back-end only CMS, built from the ground up with the cloud-first and API-first approach in mind. It decouples content from its front-end presentation and breaks it into components that can be further called upon by various services over a RESTful communication.

The term “headless” comes from the concept of chopping the “head” (the front end, i.e. the website) off the “body” (the back end, i.e. the content repository).

A headless content management system remains with an interface to add content and a RESTful API (JSON, XML) to deliver content wherever you need it. Due to this approach, a headless CMS does not care about how and where your content gets displayed. A headless CMS has only one focus: storing and delivering structured content.

The need for headless CMS

Due to the increase in demand for multi-channel publishing capabilities content authors seek an easy and long term alternative to deliver content across the breadth of supported channels, which is where headless CMS architecture comes in.

It’s also important to differentiate between a decoupled and a truly headless CMS. While both enable multi-channel content distribution, in a headless CMS, content just sits there in design-agnostic state, broken down into logical components and ready to be called upon by the APIs. This stands in contrast with the decoupled CMS that may proactively send/deliver content to various channels.

When should one use a headless CMS

The headless approach may look promising, but it comes with its own trade-offs and is not necessarily the best fit for every use case. The below list highlights some of the points to remember when trying to apply a headless CMS.

(+) Flexibility. To use the most suitable development platform and not be tied with what the traditional CMS provides.

(+) Scalability. Designed with a cloud first approach in mind, they are designed to scale being API driven.

(+) Agility. More adaptable to changes and since they only deal with content it is pretty easy to make changes.

(+) Multi-channel distribution. The same content can be applied over multiple channels, based on the view framework being used.

(-)Web Infrastructure. Since a headless CMS has no front-end. The whole web infrastructure needs to be managed separately.

(-)Preview mode. A very important feature of a CMS is the preview mode which enables the author to view how the content would be rendered. This feature is missing for a headless CMS or needs to be built separately as a web app.

(-) SEO. Many of the SEO capabilities provided by traditional CMS have to be re-engineered and re thought of while using a headless CMS.

Keeping the above points in mind, in my opinion a headless CMS can prove to be worthy for the below use cases

Non-web content publishing, i.e, content to be used outside of a typical website for example mobile apps.

Multi-channel publishing, i.e, instances where content is being pushed into multiple channels: web, mobile, print, etc.

Content aggregation, where content from multiple sources is being aggregated in one place to power a website or an app.

“Subservient” content management, where content isn’t the main point of the application. In these situations, content is used as part of a larger application that can’t support a CMS directly.

Editorial segmentation, in cases where in we want to have a subset of content authors doing a limited and a very specific authoring and don’t require access to the core CMS system.

Which Headless CMS to choose?

Now that we have seen what is a headless CMS and why should one be using them. Let us now look at a comparative study of few of the popular headless CMS available in the market.

Directus : Powered by PHP and Backbone.js, Directus is an open-source tool that wraps custom SQL databases with a dynamic API, and provides an intuitive admin app for managing its content.

• Features a fully decomposed and extensible library.
• Mirrors exactly what’s in SQL database. Thus the database models are directly mapped as content models.
• It is completely free and open-source and supports both on-prem and cloud instances.

Contentful : Contentful is a content management developer platform with an API at its core. It provides for total freedom to create specific content model which are easier to manage and categorize.

• Focuses on content centric approach and decoupling it from any template or pages. Thus separating content form presentation.
• All the created content is accessible via an API, thus providing for multi-channel capabilities.
• Supports only cloud managed instances.

Strapi : It is an open-source, Node.js based, headless CMS to manage content and make it available through a fully customizable API.

• Elegant, fully customizable and extensible admin panel
• Plugins oriented
• Capable of integrating with any frameworks

Summary

There is no CMS applicable for every use case. A Headless Content Management System gives editors an interface to easily managing content, while providing APIs for developers to build applications, making it simpler and faster to store, edit and publish content.