Headless CMS 3.0: The Disruption of the Headless CMS Landscape

For almost two decades, marketers, content creators, and product managers have relied on a content management system (CMS) to fuel digital experiences.

The advent of the headless CMS helped brands adjust to new digital channels, devices and touchpoints on the market, but the headless CMS landscape has already changed. Here’s how.

What is Headless CMS?

In traditional CMS applications, the presentation and content layers were closely coupled. This architecture limited how content authors could render their content, and limited software developers to using CMS-specific front-end technologies. The guiding principle behind headless CMS comes from the system’s ability to split the front-end presentation layer (also known as the “head”) from the back-end content layer. The headless CMS architecture allowed software developers to craft different front-end layers using their technologies of choice, and provided content creators with simple but easy to use authoring interfaces.

Headless CMS 1.0: Pure Headless:

The first versions of headless CMS applications (known as “pure headless” or “headless 1.0”) were just as the name would imply. Instead of tightly coupling the presentation and content layers, these systems used application programming interface (API) calls to split the front-end from the back-end. Software platforms like ContentStack and Contentful offered developers the freedom and flexibility that they lacked in traditional CMS applications when choosing a front-end framework to use.

Advantages of Headless 1.0

When headless 1.0 applications first appeared, authors and developers enjoyed some immediate advantages over traditional CMS platforms. Some of these advantages include:

• Single source of content: marketers could manage content in one system instead of having multiple CMSs catering to different channels like web, mobile and more.
• Smoother integration: APIs made it easier for developers to integrate with third-party systems without hacking together custom modules that most traditional CMSs required.
• Easier front-end app development: working with APIs made it easier for developers to integrate CMS content with new front-end frameworks like React and Angular.

Drawbacks of Headless 1.0

Although headless 1.0 represented a remarkable leap forward from traditional CMS platforms, the technology was not without its drawbacks. Some of these drawbacks include:

• Lack of in-context content authoring tools: Many headless CMS systems did not have the built-in functionality to let creators write and edit their own front-end experiences in-context. By getting rid of the “head”, most systems had no content previews, versioning, WYSIWYG editors, or experience creation tools. Authoring was reduced to entering content into a form.
• Over-reliance on IT: headless CMS platforms put more pressure on IT teams because the systems required developers to create the entire front-end application, increasing the total cost of ownership as a result.
• SaaS-only: Most headless-only CMS systems like Contentful and ContentStack are also SaaS-only, which lock users into a single vendor and expose them to the negative consequences of the SaaS trap.

Headless 2.0: Hybrid Headless

The next generation of CMS sought to leverage the advantages of the headless model while removing many of the obstacles found in the first iteration. The “headless 2.0” model (also known as “hybrid CMS”) sought to combine the user-friendliness of the traditional CMS platform with the flexibility and portability of the old headless architecture. Many legacy CMS vendors opened up their APIs and then called their systems “hybrid”, but without a multichannel authoring experience, that’s not quite true.

Advantages of Headless 2.0

The headless 2.0 CMS has numerous advantages over its predecessor. Some of those advantages include:

• More user-friendly features: The best hybrid CMS platforms will include an author-friendly user interface and a content publishing system that features a WYSIWYG editing suite.
• Front-end templates: While headless 1.0 CMS users must develop their own front-end templates, headless 2.0 CMS platforms often come with pre-formatted templates.
• More freedom to create: A headless 2.0 CMS gives content creators more control in engaging their customers across multiple channels, while also empowering developers to integrate advanced tools and provide better user experiences.

Drawbacks of Headless 2.0

As with most technological advances, the move to headless 2.0 was not without its problems. Some of the drawbacks of the headless 2.0 architecture included:

• Not every hybrid CMS is the same: Some vendors claim to have a “hybrid CMS” that simply uses API calls, much like headless 1.0 platforms, and lacks many other features. Many traditional systems that now serve content via APIs aren’t actually headless 2.0 because the WYSIWYG editor still isn’t usable for multichannel authoring.
• Difficulty maintaining environments: with a database-driven architecture, it’s difficult to replicate content across environments, often requiring manual copying and syncing of content by DevOps teams.
• Lack of Scalability: headless architectures usually share a content repository between the authoring and delivery components, leading to bottlenecks and potential limitations from trying to replicate databases at scale.

Headless CMS 3.0: Extensible APIs, GraphQL-ready, and the DevContentOps Process

While headless 2.0 systems help marketers manage content across a few more channels, the newest iteration may be more in line with fulfilling the expectations for omnichannel delivery. The latest version, what we are calling “headless 3.0”, offers an advancement over the dependence on fixed, vendor-specific REST API calls. Headless 3.0 includes extensible APIs allowing developers to create their own, along with native support for GraphQL, and support for weaving the content management process into traditional DevOps, also known as the DevContentOps process.

Advantages of Headless 3.0

Why do extensible APIs, GraphQL support and the DevContentOps approach mark a new era in the headless CMS evolution, you ask?

• Fewer API calls: With vendor-specific REST APIs, applications often require multiple trips to the backend for separate resources, but extensible APIs allows developers to create their own to improve efficiency and performance. And GraphQL doesn't couple the description of a resource with how it's retrieved.
• Less bandwidth usage: Another issue with fixed REST APIs is over fetching, or retrieving more data than the front-end needs. Again, extensible APIs allow developers to be more efficient and optimize performance. GraphQL lets developers request what they need, so apps don't waste bandwidth.
• Better developer experience: GraphQL is descriptive, and therefore, intuitive for developers to query against. CrafterCMS has native support for GraphQL out of the box, eliminating the need for developers to build the backend.
• DevContentOps™: the need to manage and sync content across environments was not met with traditional database-driven CMSs. With git-based content repositories, content workflows can take on a CI/CD approach. This ensures content and code can easily be pushed and pulled to different environments without the difficulties of database migrations.

CrafterCMS: The Next Generation of CMS

The headless CMS landscape is no longer monolithic. When choosing a headless CMS, you need to be aware of the different types of headless and decoupled systems on the market, as explained above.

At CrafterCMS, we’ve taken the concept of headless content management all the way to version 3.0. Our decoupled CMS architecture completely separates the content authoring system (Crafter Studio) from the headless content delivery system (Crafter Engine). This separation allows marketers to enjoy fully-featured, in-context and WYSIWYG content authoring tools, and also allows for centralized content to be distributed to any app, device or channel.

Many traditional, and even headless, CMS vendors claim to be decoupled, but in reality, their authoring tier and deliver tiers are connected via database sync -- a slow process and IT operations nightmare. With CrafterCMS, you’re truly decoupled, and truly headless. CrafterCMS provides extensible API support, allowing developers to create their own REST APIs, and provides native GraphQL support as well.

With all content stored in Crafter Studio and its underlying distributed, git-based repository, marketers and brand managers can be sure that their content will remain consistent across all apps and channels—and across any other touchpoint that they wish to include in their digital experience. And true DevContentOps process support allows software developers and IT operations to work with the content authoring teams without any friction or bottlenecks

At CrafterCMS, we’ve prioritized the authenticity of our decoupled architecture, an architecture that empowers content creators and frees the IT department from having to support business initiatives at every turn.

Here’s how our truly decoupled architecture has benefited global brands and publishers including Marriott and Harvard Business Publishing.