Headless CMS, what is it and should you decouple?

A blog by Elisabeth Escribano, Software Architect at Youwe

You probably have heard of a headless Content Management System. If not, then you are finding out what this is, right now. A headless CMS is very popular at the moment. The terms headless and decoupled are big trends in the digital world. But what do these terms mean?

First of all, there are different terms used. Some people talk about a headless CMS and others talk about a decoupled CMS, but these terms are synonyms. So, they are exactly the same! With a traditional CMS, the Content Management Systems controls both the backend and the frontend. So, if you, for example, are using Drupal as a CMS then Drupal has complete control over the presentation and data layers. When you choose for a headless approach. Then the CMS has control over the data layers but has no responsibility for how the data is presented. In a headless approach, the frontend is decoupled from the backend. 
 
With a headless CMS, you also have different kinds of versions of decoupled systems. You can progressively decouple or fully decouple. 

Progressively decoupled

When you are not entirely sure if a headless approach is the right solution for you then an in-between solution is to progressively decouple. This means that your CMS for example Drupal is still partially responsible for the presentation layer, but JavaScript is required to offer the interactive user experience that is desired. In this scenario, the JavaScript framework is layered on top of the existing CMS front end. The responsibility of JavaScript is limited in this case. 

Fully decouple

The other choice is to fully decouple. Then the CMS is purely the data provider. The JavaScript framework is solely responsible for the presentation. This means that all rendering and markup are communicating with the CMS via web services or APIs. The great benefit of a headless approach is that one JavaScript framework can be used for different data providers. This is because, as said as earlier when you chose a headless approach, the frontend and backend are decoupled from each other. 
 

Should you choose a traditional CMS or a headless CMS?

So, now the big question is: “Should I stay at my traditional CMS, or should I choose for a headless CMS? This all depends on your requirements, purpose, long term plans and budget. It is not an easy decision to make. And there are pros and cons either way. The following points will hopefully make your decision a bit easier.  

Why should I decouple?
  • A headless approach will give you an improved user experience;
  • You are not only reliant on backend developers;
  • Use the same decoupled frontend on different backends. The great benefit of a headless approach is that one JavaScript framework can be used for different data providers.
Why shouldn’t I decouple?
  • Architecture is more complex because you have to maintain multiple systems and to maintain your site and adding functionalities work in different systems;
  • Finding bugs gets more difficult. The eternal question will always be: “is it a frontend or a backend bug?”;
  • You have to hire the right people. Now your website has two different teams a backend team and a frontend team. 

Do you first want to figure out which CMS is the right one for you?

Download the comparison of Drupal vs. TYPO3 vs. WordPress and find out which open-source CMS is the best for your organization.