Coupled, Decoupled and Headless Content Management Systems
Every day we see more and more devices coming to the market. 2014 - opensignal.com published a graphic of all the android device fragmentations - over 18.000 only for android devices (still growing), not even mentioned smart watches, VR experiences, wearable technologies, TVs; high-end toaster or your smart home hub.
The explosion of different devices, platforms, and apps is changing the way we consume and present content.
So what is the status quo? Which CMS architectures currently exist, and what are the pros and cons of them?
Traditional / Coupled CMS
Everybody knows those systems - maybe not by the name “Traditional” or “Coupled” CMS but if I say some brands like WordPress, Squarespace and so on. You can think of them like monoliths among the CMSes out there. From a more technical point of view, a coupled CMS consists of:
- A local database where the content is stored
- A content management backend to create and update content
- A predefined set of technology and structure the developer is forced to use and create the front-end with.
- Reuse of content for different systems needs to created or only available using a plugin.
- Hard to mix up with other systems like existing e-commerce or product databases.
Decoupled / Headless CMS
A headless CMS has its front-end part removed, and what still remains is content delivery via an API or static content files, some would also name those content management systems “API driven CMS”. Its focus is just on storing and delivering the content, and provide some kind of CRUD part. This means that the content of a headless CMS can be used on a website, an app, a wearable device or even your new high-end toaster.
We know that more and more websites are built with the headless CMS architecture, even WordPress tries to change from being a monolith to an API-driven CMS the so-called “headless WordPress” or “Headless Drupal”. Both of these options try to make the CMS work in a way that they were not designed for. In fact, they won’t scale that properly, since their monolithic nature doesn’t allow them to be as extensible and performant as needed.
The technical view on a headless content management system would be:
- An open content management API
- A completely free choice of technology for developers to work with
- Reuse of content for different systems out of the box
- Mix up and match with existing CMS, E-commerce or other systems.
|free choice of technology|
|front-end editing capability|
|easy to scale for high traffic|
|themes and templates|
|directly supports native apps|
|possible page-oriented approach|
|custom field types|
Decoupled/Headless CMS - Storyblok
Most headless CMS tend to introduce the current generation of editors to a completely different mindset and also removes the possibility to have a page-oriented approach with layouts or grids, but we don’t have to do so. Storyblok was designed to bring the best of both worlds - headless - so you can create your content as you need it. Components as collections (blog posts, award entries, …) but also components as a part of a layout, a grid, a column, a headline.