What's the difference between a coupled, decoupled and headless CMS?

I was listening to a conference talk recently that started using the term 'decoupled' CMS. I'd only ever heard of traditional and headless, so I did some curiosity research.

As usual, this article will serve future me if I forget what the difference is but hopefully it will also help anyone with the same question.

What is a traditional CMS?

A traditional CMS is one where the front-end (presentation) and back-end (database) are stored in the same place and are heavily dependant on each other. An example would be a traditional WordPress site.

What is a decoupled CMS?

It turns out what I thought was a headless CMS is actually a decoupled CMS. A decoupled CMS is when, for example, you have a site where the front-end and back-end are housed separately. The front end uses API calls to get the database information from the back-end and then displays it.

What is a headless CMS?

A headless CMS is a type of decoupled CMS. The main difference is that a decoupled CMS typically has a front-end and a back-end, where a headless CMS is a content-only database with an API that can be called. It should be designed in a way that the content from the database can be ingested and displayed by a variety of methods/technologies (to a website, to an app, etc.) through API calls.

Which one to choose for a project?

For basic sites and blogs, there is nothing wrong with a traditional CMS system. The major downside is that your project is tied to a specific technology and isn't as future-proof as a decoupled CMS could be. Out of the box, a traditional CMS is less work if you know what you're doing, but more work if you have to make major front-end changes in the future.

For more complicated sites that need longevity, a decoupled CMS is a good way to go. While it may be more work at the beginning, it's more flexible and easier to adapt in the long-term. This is also a better option if you or your team like to experiment with different technologies.

For projects that require information to be ingested by multiple presentation methods, a headless CMS is probably the best route to take. If a website is part of the project, then that can be built and pulled via the API but so can all the other delivery methods your project may require.

Photo credit: Photo by Devon Janse van Rensburg on Unsplash