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.

device fragmentation by http://opensignal.com/reports/2014/android-fragmentation/e

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?

1. 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.
Storyblok editing capabilities

2. 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.
Decoupled/Headless CMS

Actually, the whole CMS part can be reduced to the Content management backend and the content delivery API. The only reason for the content management backend to exist is that it should be easy to create and update content - and the developer of the frontend should not worry about the admin view each time. The frontend developer itself only has to know which components exists and render them according to the information they receive. Just to make things clear - a frontend can also be a server-side rendered website - it doesn’t require a javascript frontend.

Let's compare:

Traditional/CoupledDecoupled/HeadlessStoryblok
platform agnostic
free choice of technology
front-end editing capability
highly customizable
easy to scale for high traffic
themes and templates
directly supports native apps
possible page-oriented approach
code simplicity
custom field types
localization

3. 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.

While we can say that there is no single right approach and CMS for every use case, we strongly believe that the free choice of technology, paired with the possibility to still go with the page-oriented approach if needed and also be able to create data structures for all kind of collections and all the other up-sites of a headless CMS will help make building most of the real-world projects easier, faster and with a better quality, and this is why we built Storyblok.

Summary

“Content management is all about delivering the right information to the right destination at the right time,” said Jeff Yoshimura, VP of Worldwide Marketing at Elastic.co

We believe going headless will be the next step in boosting your online success. You will be more flexible, prepared for new devices, and have no worries to scale for high traffic. You can even switch your whole technology stack if your company wants to switch without creating the whole content all over again. Relaunch or an Evolution of your current website or app will not depend on how fast your editors will port your content.

– it’s already there.

We would love that you give Storyblok a try, it’s quick, easy, and free to use for small plans!


More to read...

About the author

Dominik Angerer

A web performance specialist and perfectionist. After working for big agencies as a full stack developer he founded Storyblok. He is also an active contributor to the open source community and one of the organizers of Stahlstadt.js.