Decoupled CMS: pros and cons vs headless CMS
- Marketer-friendly
- More resources and experience in the market
- Content delivery can be fast and flexible
- Design, configuration and deployment happen faster
- Better control over governance
- A more complete system
- A lot more built-in functionality
1. Marketer-friendly
Whereas a headless CMS application can leave marketers handicapped and missing the tools they enjoyed with a traditional CMS, a decoupled CMS provides ready-made tools that simplify things. You don’t need to be a technical expert to get the most out of the platform.
A decoupled CMS also includes features such as live preview and a presentation layer that enable people to see the content they’re managing and not just code, which they need a developer to interpret for them.
(Core dna live preview editor)
2. More resources and experience in the market
A decoupled CMS combines the best aspects of a headless CMS and a traditional CMS. This allows it to leverage existing resources that are understood across the CMS industry. Whereas headless architecture is relatively new, and with front-end frameworks continuing to evolve, it can be challenging to work with them at times.
3. Content delivery can be fast and flexible
Content delivery is much faster with a decoupled CMS due to the flexibility of having templates that enable marketers to create content and deploy it to multiple platforms without working with IT.
4. Design, configuration and deployment happen faster
Since a decoupled CMS includes pre-built templates, it can be easier to design experiences and configure content to be deployed than a headless option, which needs to wait on a front-end to be created.
5. Better control over governance
A decoupled CMS provides more control over the front-end frameworks available for developers, which improves content governance.
While a decoupled CMS is frontend-agnostic, it’s possible to limit developers to specific frameworks to improve consistency and make it easier for developers to work together.
6. A more complete system
A decoupled CMS is essentially a complete system as it provides all of the front-end tools, templates, and functionality necessary to build complete solutions.
Unlike a headless platform consisting of only a back-end that needs to be connected to templates, the front-end is already available in a decoupled CMS and simply needs to be connected via an API. A decoupled CMS also includes the back-end infrastructure and networks for increased accessibility and security.
7. A lot more built-in functionality
Headless platforms can place limits on developers, forcing them to create everything from scratch. With a decoupled CMS, there are existing templates and reusable building blocks, which means that everything doesn’t need to be developed from scratch each time.
Decupled CMS cons vs headless
- Generally larger systems
- Not as focused on the developer experience
- Has a lot more tools that people may not need
1. Generally larger systems
Headless systems are smaller and easier to manage. Whereas with a decoupled system, there is a lot more to manage and configure to get the system to work.
2. Not as focused on the developer experience
A headless platform was made with developers in mind and therefore focuses exclusively on the developer experience.
With a decoupled CMS, there is more of a balance between what marketers require and what developers require. This lack of focus on the developer experience means that a decoupled CMS may sometimes place unintended restrictions on developers similar to a legacy CMS.
3. Has a lot more tools that people may not need
A decoupled CMS also has more tools than the average developer or marketer might need to be successful. These added features can be beneficial for larger organizations with multiple departments that can make use of them. However, sometimes decoupled CMS users may be left with several features that they don’t need.
Decoupled CMS example: A case study
A great example of a decoupled CMS can be found in how the SEEK marketing team uses Core dna CMS to create content in a “traditional way” with the help of a rich-text editor that lets them fit content page elements into place with ease.
The SEEK development team can then consume that content in other systems, through APIs, without having it tightly coupled with Core dna like it would be in a traditional CMS.
Traditionally, a CMS delivers server-side rendered content (SSR). Essentially, you enter content, and the CMS renders you a page on the website using a templating language.
With SEEK, content is delivered headlessly in a structured data format (JSON). A customer sends a request, and then the entire page is delivered to them at once. The structure of this data can also be customized based on client needs.
Rather than relying on the CMS to manage templates that present data in HTML, data is consumed in JSON format, and the page can be rendered using any front-end technology that the SEEK team wants.
To render this content on the page, SEEK makes a request using Core dna’s Headless API. With conventional APIs, several requests are required to render a page that contains a blog post, author information, related posts, and the most popular posts written by that author.
Instead, with Headless system, a JSON view template is created, and the information to fill that template is gathered all at once. Content is fetched in an easy-to-consume way as one large JSON object.
This provides the SEEK team with a completely tailored approach that only gives them the information they need without redundant data or excess API calls.
SEEK also requests content updates that have been created, modified, or deleted. This also reduces the number of HTTP requests between the two systems which reduces the risks of network connectivity failure.