What is the difference between a Coupled, Decoupled, and Headless CMS?

While technology continuously evolves, so do the devices we use to present our content. The need to support various applications and devices, as well as future-proofing new technology implementations, is forcing content management systems to act smarter. In this article, we'll examine the difference between three types of content management systems: coupled, decoupled, and headless CMS.

Coupled (Traditional)

"A traditional CMS allows content creators to produce, publish, and manage content in the backend, while providing a content delivery layer on the frontend, which is almost always in the form of web page templates." [source]

This type of traditional architecture is included in out of the box installations of popular CMS like WordPress, Drupal, or Magento. It's a package deal scenario, both the database and presentation layer is packaged together regardless of who or what device is accessing that data — they are tightly coupled. Some characteristics that would tip the used of a coupled CMS include:

* Content is stored locally in the database
* The CMS provides a front-end technology for the developer to work with to make themes and templates
* Integrating content from other systems needs to be done via a plugin or module

But content consumption is an ever-evolving beast, things change rapidly and larger companies can get more value from a content management approach that let the marketing and content producing team evolve at their own paces and keep up with the latest and greatest.

This is how we got the headless CMS.

Decoupled (aka Headless)

Headless architecture allows marketing teams to experiment with changing things up without needing to rewrite their CMS. By separating your frontend from the backend, it’s easier to redesign it in the future, without changing the CMS. Also, front-end developers only need to care about what to do with the data the backend provides them. This kind of CMS removes the front-end delivery layer from the picture completely, leaving nothing more than the backend – which acts as an over glorified content bucket.

Some features of a headless CMS include:
* The developer can use any technology to present their content – like using ReactJS, Vue or Angular to deliver highly dynamic web app.
* It’s easier to build a PWA (progressive web app) should the need arise.
* Front-end and back-end components communicate with each other through API calls.
* Better website security – exploiting the website becomes more difficult since it’s largely non-public facing.

Decoupled (non Headless)

This type of decoupled CMS keeps the front-end delivery layer (ex: website templates, layouts, WYSIWYG editors) – all while allowing for headless content delivery.

For example, a decoupled WordPress is an "application that uses the WordPress database (the back end) but not the front-end user interface". A decoupled CMS gives content creators ready-made templates and easy-to-use tools for creating and publishing content. This architecture combines the flexibility and adaptability of headless CMS and the user-friendliness of traditional a CMS.

Summary

The decoupled architecture is still fairly new. While techniques are getting better, the path is still not what anyone would call well-worn. Each architecture has its pros and cons and may be more appropriate depending on the needs of your business. There is a strong consensus that going headless will be the next step for many applications as you can upgrade to the latest and greatest without downtime or creating the content all over again. The decoupled model is already being used today by developers in both Drupal and WordPress, and future releases will deepen support. WordPress & Drupal 9 both include a JSON REST API built-into its core, so expect to see further developments like these driving headless/decoupled architecture!