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
Top comments (3)
Hi Melanie, being quite new to development I've been thinking about this recently, so thanks.
Do you mean that a headless CMS is limited in the freedoms or the flexibility of the backend? As in, current headless services are simply portals with their own CDNs and database systems that don't provide backend access to write whatever functionality you want?
The way I understand it is that a headless CMS shouldn't be built in a way that it's limited to how content can be delivered. It should be built so it can be called easily using various methods, whether you're trying to display the info in an app, on a website, etc.
A decoupled CMS likely has a specific front-end presentation layer that is built and housed separately from the back-end.
For example, if you wanted to build a website using Gatsby (or any static site generator) on the front-end but use WordPress as your back-end, it would be a decoupled CMS. This is because the WordPress API is built on top of something that is primarily geared towards displaying information on websites.
Many traditional CMSs (WordPress, Drupal, etc.) are adding APIs on top of what they already have so users have the option to use traditional or decoupled. But headless CMSs typically use APIs exclusively to deliver content, there is no traditional/coupled option.
I hope this answers your question? :)
Yep, certainly does, thanks! π