Traditional, Headless or Decoupled: The New State of CMSs

Headless CMS is a term that has been on everybody’s lips recently, along with Content as a Service and Decoupled CMS. Actually, these three concepts are very closely related; you can’t talk about any of them without citing the others as well but, for a better insight on the topic, talking about the idea of Content as a Service is a good starting point.

The first CMSs were born in the early 2000’s as authoring tools to create and manage websites: everybody surfed the web with a desktop computer or, to a lesser extent, with a laptop so the final output was the standard HTML page. As technology progressed and modern smartphones hit the market, some developers argued that the content had to be delivered to users in a mobile-friendly and optimized way. Taking a standard html page, with large images optimized for desktop view, and heavy-loading scripts and assets and therefore tweaking it for a good mobile view, is a waste of resources that are quite scarce on mobile phones (especially when the mobile hype started). But there are not just mobile phones out there; new devices enter the market even as we speak, like watches or smart-home devices and many more will add to that list in the very near future. This is what Content as a Service is about: have the content produced just once and then delivered to every device in the best individual format, namely breaking the strong dependency between the content creation and its output display.

If we apply the concept of Content as a Service to the logic of a CMS, we start figuring out what a headless CMS is about. In a standard CMS we have a content creation layer, a repository (a database) and a delivery layer. The latter has the purpose of turning the data from the repository into real HTML pages. In a Headless CMS we don’t have the delivery layer (the “head” of our CMS): the content is stored in and delivered from a repository as structured data (often JSON) using a RESTful API. One could wonder what happens to the data at this point, and that is the concept of a headless CMS: the data simply does not go anywhere, it’s fetched by the front-end client by means of the API provided, so that the output is optimized for every device instead of having a single output, tweaked and scaled in multiple versions.

Of course, building a custom front-end means more work but we make a huge leap in terms of flexibility, when we need the data to be displayed on different outputs (the terminals of an airport could use the same data on the website as well) or when a company has specific needs for the front-end and a traditional CMS’ approach would be too limiting. On the other hand, using a headless CMS does not fit every situation and can lead to a meaningless increase in costs and time: a company’s presentation website, even a complex and highly interactive one, can make a good use of the traditional CMS’ presentation layer with a good built-in responsive strategy.

So, we have now a separation between the content creation process and the delivery to one or several platforms by means of APIs: basically the headless CMS, once it has delivered the content that was queried, has completed its task. It's now up to the custom front-end to take care of what will be following. Sometimes it is better to extend this approach and take care of what’s happening after and, in this case, we are moving into the territory of decoupled CMSs

Scrivito has a very nice and powerful content management interface (the delivery layer we were talking about before) and it spots a high degree of customization that perfectly fits in most of the cases when one could think about making a custom front-end (something that does not come lightly, from the costs point of view). But Scrivito supports multiple heads, therefore becoming the perfect solution for companies that want to build a dedicated front-end for a particular device (wearables, for example) without loosing all the advantages of a powerful and fully-customizable content management interface.