The guide to headless and decoupled CMSs

This article will teach you what a headless CMS is. You will also learn about the differences between a headless CMS like Contentful - and more traditional CMSs like Drupal and Wordpress.

Table of contents

• What is a headless CMS
• How a headless CMS is different
• Audience and use cases of monolithic vs headless CMS
• Popular headless CMS options
• Contentful, the API-first content management backend
• Summary

What is a headless CMS?

A headless CMS is like a traditional CMS but without a front-end. What remains is a backend delivering content via a RESTful API. Because of its backend-only nature, a headless CMS does not care about how content get displayed to the end user. A headless CMS stores and delivers content – nothing more.

Its counterpart is the standard multi-purpose CMS – often referred to as monolithic or coupled.

Take the multi-purpose CMS WordPress for example. The platform has several key components:

1. The database where the content gets stored.
2. The web app in which editors work with the content (also known as the admin interface).
3. The part of the web app for managing the website's design.
4. The front-end that pulls content from the database to generate HTML pages.

Imagine that we remove component number three and four. The head of the CMS, the website itself, would no longer be there: what remains is a backend for handling content storage and distribution – together with a web app for editors. You now have a headless CMS.

Unlike using monolithic CMS, a website can't be built with a headless CMS alone. By design, a headless CMS lacks the features to do so. This is mainly because there's no concept of themes or templates. A developer must therefore build the website herself, and then use API of the headless CMS to pull in the content.

Having to create the website part of a CMS-based solution may seem like more work. And some may say "working with a single software is simpler than working with two", or "building a front-end is hard and time-consuming". These are fair points, and they do apply to a variety of cases. This is why there is no definitive answer to the question "is a monolithic CMS better than a headless CMS?". The answer is – it depends on your needs. There are use cases where one CMS type is better than the other.

Use cases for a headless CMS

Some use cases for headless content management include:

• Websites and web apps that use JavaScript frameworks such as React, AngularJS, and VueJS.
• Mobile apps.
• Websites built using static site generator.
• Ecosystems of apps and websites where the same content gets published in many places.

A headless CMS is a good choice if you feel limited by the front-end restrictions of a standard CMS. Rich web apps, custom layouts, and JavaScript frameworks don't quite fit into the architecture of a CMS which closely controls how content looks. To keep development simple it's better to have a clean setup from the beginning.

It's not only for websites, though. A headless CMS usually delivers content through an API, which means that it can deliver content anywhere, on any device. This is great news for mobile app developers, because with this approach the same backend can deliver content to an iOS app, an Android app, or any other medium.

A headless CMS is good for cross-platform publishing and custom user experiences. It makes publishers, designers, and developers happy, who in turn will provide great products for their users.

But if your use case is just a company website with only a handful pages, a headless CMS might not be the way to go. WordPress would in this situation be a faster way to get the website of the ground.

Popular headless CMS options

Traditionally monolithic CMSs have been trying to fix their mistakes and promote themselves as headless. The most popular PHP options for going down that path are:

• Headless Wordpress, with JSON API plugin. It's possible to install the JSON API or JSON REST API plugins on top of WordPress, and use it exclusively as a headless CMS. This setup offers a simple API, and it has the advantage of keeping the same software and editorial workflows as ever. However, they're still third-party plugins, which means that there is no official support, they offer limited capabilities, and as with many WordPress plugins, they could cause conflicts with newer versions of the software, or even security problems.
• Headless Drupal: RESTful module or Drupal 7 with RESTful Web Services module; Drupal 8 actually includes a RESTful Web Services module in its core. Thanks to the huge Drupal community and core support, this may seem like a good choice. However, Drupal is fundamentally a tool for building websites the Drupal way, which can cause problems when deviating from that path (especially in the case of app development). Furthermore, Drupal's architecture hardly plays well with the lean and fast approach which is often required when adopting a headless CMS, therefore performance is often an issue.

These two options try to make traditional CMSs work in ways they were not designed to. In fact, both WordPress and Drupal don't scale well when using them as headless, because their monolithic nature doesn't allow them to be as flexible and performant as needed.

Contentful, the API-first content management backend

Unlike Headless Wordpress or Headless Drupal, Contentful was built from the ground up to be a headless CMS. This means that you won't find many of the unsatisfying things that you would see in a monolithic CMS that was repurposed to be headless, such as insufficient performance, limited capabilities, bad documentation, and inconsistent support.

A short side-by-side comparison of Contentful vs. Drupal vs. Wordpress can be found here.

Of course, this requires you to adopt a different mindset and introduce concepts such as content modeling and search-based management (instead of tree-based). However, we are sure that the advantages that this new paradigm can provide are real and substantial, which is why the change is worth the effort.

Summary

There is no single right approach and CMS for every use case. We do however strongly believe that separating content from presentation is crucial when building modern applications – that's why we built Contentful.

If you want to quickly build something with Contentful you can check out our Contentful in five minutes guide.

So give Contentful a try, it's quick and easy — and free for small plans!