Should you consider headless content delivery?
“Headless” is a term that is used to refer to CMS products that do not provide a rendered view of their content but instead deliver the content as structured data. Increasingly, the term API-first is being used as a way of describing these CMS products.
What is the benefit of going headless? The primary benefit is that the actual display of the content can be done by front-end code that can adapt the display to the contex. Rather than delivering HTML markup of a product description, a mobile app might want to present that information using native controls for example.
Being able to choose the display technology allows customers and partners to have teams with specific expertise handle the front-ends for different platforms or channels. This allows you to the best use of each platforms features, enables innovation and parallel development. Headless also helps site owners future-proof their implementations by allowing them to refresh the design without re-implementing the whole CMS.
Ultimately, headless content delivery is a model of separation of concerns, which helps explain its rising popularity in the development world. A mobile app team can work in whatever technology and development environment they need and integrate managed content.
The second most important characteristic of headless delivery is that it is fundamentally a "pull" model – content lives somewhere and is pulled on-demand into the context. A decoupled CMS, like Crownpeak DXM, operates on a push model so that when content is ready for publishing, the "view" is actually published from the CMS to the content delivery environments.
Blend Interactive CSO, Deane Barker, summed up the difference between decoupled and headless content management like this:
“A decoupled CMS is proactive — it prepares content for presentation and pushes it into a delivery environment. A headless CMS is reactive — it manages content, then just sits and waits for some process to ask for it.”
Why is headless gaining traction?
The simple answer is that there are an increasing number of channels that content needs to be delivered to — and many of them are not visual – think Alexa, Google Home and other voice assistants – let alone not web-based. In order to deliver content to these channels, marketers must be extending their implementations and often this cannot be done by just targeting the worldwide web. Responsive design was the mechanism for targeting desktop and mobile devices but was still fundamentally about the web and therefore HTML.
Like any CMS, a headless CMS provides editorial tools to create and edit content. The difference comes in when you look at content delivery. “Publishing” in a headless architecture just means making it available via an API — the CMS assumes that a front-end development team can handle the rest with whichever frameworks and tools they prefer.
A headless CMS approach would allow a new channel, like smart speakers, to be targeted without impacting on any existing channel content delivery.
There are a number of other use cases where headless is considered advantageous:
- non-web content delivery
- multi-channel
- content aggregation
- systems or apps where content is secondary (mobile banking app or finance portfolio app)
Headless isn't a good fit for everything though. If you just need a mobile responsive campaign site, a typical “single repository, single website” implementation, then headless would bring very few benefits over any other type of CMS.
Conclusion
Coming back to the question posed in the title: should you be considering headless delivery? Absolutely.
The immediate follow-up question is whether Crownpeak DXM can also handle these use cases. Crownpeak DXM does everything a headless CMS does in terms of content creation and editing, and more. DXM adds templating tools to help create a view or rendering of the content, or multiple views if necessary. These views are then published to a delivery environment, typically a web server but certainly not limited to that.
Crownpeak also offer Search G2 which can be thought of as a document database that can be queried to populate content displays.
In the next articles I'll be looking at each of these use cases where headeless is considered an advantage and showing you how the same thing can be done with DXM.
