Headless content management system

Most headless CMS platforms employ a version of these features:

• GraphQL API
  • Query and Mutations API
• RESTful API
• Microservices architecture
• Multi-channel publishing
• SDKs and CLIs
• Editor interface
• Workflows
• Versioning
• Roles and permissions
• Content modelling
• Asset library
• Content types and taxonomy
• Localization
• Visitor segmentation
• Personalization

Most monolithic content management systems are 'coupled', meaning that the content management application (CMA) and the content delivery application (CDA) come together in a single application. This makes back-end user tools, content editing and taxonomy, website design, and templates inseparable.[9] Coupled systems are helpful for blogs and basic websites, as everything can be managed in one place. Conversely, in a coupled CMS, CMS platform code is tightly connected to any custom code and templates, so developers have to spend more time on installations, customizations, upgrades, hot fixes, and more. They cannot easily move their code to another CMS.

Traditional content management systems are often seen as the easiest and most cost-effective way of creating dynamic websites. Popular templates and themes make it straightforward to carry out basic website design, while freelance developers offer a range of affordable support. The traditional approach also appeals to those looking for a DIY solution, as it is relatively easy to learn how to manage and design a website using a traditional CMS.

The difference between a decoupled CMS and headless CMS is based on the inclusion of the front end in the offering: a decoupled CMS always has a front end included in the offering, even though connected via an API, hence following the decoupled architecture; by contrast, a headless CMS does not offer the front end at all, but only an API to access the served content.

In response to the introduction of headless CMSes, many traditional CMS vendors have implemented APIs on their systems, promoting them as decoupled CMSes. This approach promises website rendering capabilities along with the flexibility of a headless CMS. Yet, the APIs are still based upon a model designed for a single website, making them somewhat coupled and thus limiting the contexts in which one can effectively use the content.

A decoupled CMS and a headless one because they have a lot in common as a headless CMS is a type of decoupled architecture.[10] Like a headless CMS, a decoupled CMS separates the CMA and CDA environments, typically with the content created behind the firewall and then synchronized and pushed to the delivery environment. The main difference between a decoupled CMS and a headless CMS is that the decoupled architecture is active: it prepares content for presentation and then pushes it into the delivery environment; whereas a headless CMS is reactive: it sits idly until a request is sent for content. Another core difference is that the decoupled first offer APIs to serve content, while the latter are API-exclusive.

The decoupled architecture allows for easier scalability and provides better security than coupled architecture, but it does not provide the same support for omnichannel delivery. There are multiple environments to manage, hiking up infrastructure and maintenance costs.[11][12]

Headless CMS is a content management system (CMS) without a pre-built front-end presentation layer or templating system; instead, it provides a content repository and an API for managing the content. While this allows for greater flexibility and customizability, it can also present challenges or drawbacks for teams and organizations.[13] The main downside is that it may require more effort to set up and configure and a certain level of web development knowledge on both the front and back end.

• They require heavier technical proficiency than their monolithic counterparts.[14]
• Since there's no front-end framework built into the architecture, setting up a headless CMS requires front-end development skills.
• There is sometimes no built-in preview function for unpublished content. Editorial teams highly value this feature.
• Managing multiple systems can be challenging, and a team's knowledge base must cover all of them.
• Due to how customizable headless CMSes are, there are a lot fewer options when it comes to ready-made templates or plug-ins.
• Lack of channel-specific support
• Since pure headless CMSes don’t deal with the presentation layer, developers may have to create some functionality on their own, such as website navigation.
• As pure headless CMSes do not typically provide the concept of pages and web sitemaps, content editors need to adapt to the fact that content is organized in its pure form, independently on the website or other channels.

A headless CMS offers a solution to issues arising from the traditional approach by decoupling the front end (the "head") from the back end. This allows the front end to be reworked or changed anytime, and different front ends can consume the same content. Furthermore, the architecture of the CMS is more secure as the content is stored on a separate server from the front-end presentation, which reduces the potential attack surface.

• Omnichannel connectivity for agile marketing
• Improved developer experience
• Reduced attack surface
• Easier to migrate to new technologies
• Faster front ends due to JAMStack and static-site generators
• Increased fault tolerance
• Less infrastructure for developers to maintain
• Increased collaboration between developers and content creators
• Content scalability: write once, deploy anywhere
• Optimization out-of-the-box

• Tamturk, Venus (December 16, 2016). "The Ultimate Guide for Headless Content Management Systems". CMS-Connected. Retrieved 2018-06-07.