Headless CMS, Decoupled CMS and Content as a Service - it’s all about calling APIs

In recent days I’ve spent some time reading more about “headless” and how this will conquer the world and if I don’t use it my business will fail :D. With this post I want to share what the real risks and solutions are. I will iterate through the different concepts that are currently receiving a lot of hype. Many of those terms are blended and some people are using them interchangeably, which is why I will explain each of them separately.

Headless CMS

With the increased usage of devices beyond computers, businesses want to have a presence and display content everywhere, you name it – smartphones, watches, kiosks and even refrigerators. According to some “specialists” the best approach is to use a Headless CMS that is designed to store content and retrieve it through APIs, with no frontend attached to it. This way every frontend application could consume the data regardless of the technology stack, so your content becomes platform agnostic and the whole system is decoupled. The CMS becomes a centralized place where you store your content.

An issue comes when you use a CMS without a robust API. It limits the channels that you are able push content to. Now organizations have no way to push content to other apps, such as native mobile apps, because the content is specifically designed only for browsers. Said a different way, you need your content to be in pure text or at least in a standard format.

Decoupled CMS

What if the standard CMS follows the best practices (I believe that everyone should, if they don’t, please don’t use it in the first place :D), and it has decoupled architecture and that exposes APIs and cleanly manages the content? It seems that you will be able to publish content everywhere.

The conflict with many of “headless advocates“ and the press is that your CMS will have a “head” because you have a dedicated frontend. However, with the API-first approach you can tackle the problem with multiple device content delivery no matter what. Keeping your “head” does not obligate you to build the frontend with the built-in functionalities, you can still use a framework of your choice – Angular, React etc.

Content as a Service

Having the concept of the “headless CMS” immediately brings another level of abstraction that could be built on top of it, which is “headless CMS” delivered via SaaS. This model is heavily promoted as superior to a standard CMS, but content as a service is really just a CMS hosted in the cloud and used to store content. Unfortunately, I couldn’t find any compelling arguments why this approach is better, since the cloud deployment is relatively easy and it is done by only clicking a button (e.g. Azure). Keep in mind that developers love to have control of everything, especially when we speak about APIs and deployment.

Tracking customer journeys when “headless”

The other challenge is when your frontend is created with a different technology and it is not deployed out of the box with your CMS. Usually the CMS has built-in personalization and customer journey tracking, but using 3^rd party frameworks you need to implement these things yourself. The headless advocates are often met with resistance by marketers as they feel the headless model limits their ability to leverage tactics like personalization and customer journey optimization across all apps. However, leveraging a technology that easily integrated 3^rd party data and applications enables marketers to quickly leverage any tactic they desire, regardless of the app.

One size doesn’t fit all

There are many headless CMS systems on the market and they have their success stories, but I wouldn’t say that we should abandon the standard CMS solutions, especially those that have good architectures and decoupled APIs. They are better in many ways but you may never have thought about them as headless 😊 especially when they are not advertised as such.

All of the hype is centered around two problems – coupled architecture and inability to deploy in the cloud. Those two problems were solved many years ago by every top CMS on the market and no matter what the fuss is all about, the root of everything is simple calls to APIs and quick deployment in the cloud. If you don’t believe me ask your developers 😉.

If you are interested in how Sitefinity could be used as a “headless” CMS with a brain, please read the following article.