Should You Go Headless? Leveraging a Headless CMS for Modern Digital Publishing
While it sounds like something out of Washington Irving, the mention of a “headless” CMS should not inspire images of Ichabod Crane and the frightened denizens of Sleepy Hollow. Headless CMS implementations—or “head optional” as Real Story Group’s Tony Byrne prefers—are those which separate content presentation from content management. Like a headless server, which is just a machine running without a monitor attached, a headless CMS has no presentation layer tasked with displaying content to the end content consumer.
Instead, a headless CMS makes content available via an API or intermediate format—typically some flavor of JSON or XML—to multiple different frontends or “heads.” These other applications take ownership of retrieving content and displaying it to audiences, leaving the CMS to focus only on the management of content data. With WordPress, for example, headless can be accomplished utilizing the REST API, using the admin dashboard for content creation but serving this content via JSON to content display channels (Eg. a website, a native app, etc). Most web CMS platforms today support the technologies necessary to implement “headless.”
Why Go Headless?
web CMS platforms today support the technologies necessary to implement ‘headless’
Even for projects that only require a single content destination, there are benefits in adding a layer of abstraction between the technology which manages the content creation, editing, and workflow from the technology which facilitates content presentation.
First, there’s a natural pace-layering advantage. The frontend presentation of content invariably changes more frequently than the underlying data structure managing it. Imagine being able to fundamentally transform a website’s frontend (not only a “design refresh” but a completely new user experience) without the capability limitations of the current CMS. For that matter, imagine swapping out the backend content management platform while keeping key consumer-facing interfaces undisturbed. (I’ve seen my share of “simple port with no redesign” migration projects, attempting to move a web experience from one CMS to another. They are inevitably more complex than first imagined, as one uncovers all the idiomatic and particular methods CMS platforms use for theming and presentation).
Second, there’s a clear security benefit in keeping the code which manipulates the underlying data unexposed to the outside world. Protecting the CMS responsible for workflow, content editing, and approval behind a firewall—and allowing only very restricted content retrieval operations through that firewall—significantly lessens the risk of outsiders gaining unwanted access or injecting malicious exploits. Further, if the content management system goes offline or has to be taken offline for maintenance, upgrades, or related work, the separate content presentation methods can continue uninterrupted.
Third, starting out with a headless methodology cuts down on the future effort needed to add new distribution channels. For instance, the short-term plan may be a simple website presentation, but building in a headless fashion from the beginning can be a smart strategy. Using a headless methodology will allow for the creation of mobile app syndication down the road without resulting in significant repetition of work.
Why NOT go headless?
Given the advantages of separating presentation of content from its underlying structure, why wouldn’t you choose a headless approach?
If you’re only publishing content to a single destination, you might find that the headless approach complicates the overall project, adding layers of abstraction that aren’t needed and requiring highly structured data definition that doesn’t add value. Further, if you’re dealing with substantial existing content created under a previous tightly-coupled model, the likelihood of it already containing inline styles and markup is high. This runs counter to the full separation of headless demands.
If you have a broad, global internal team as well as outside contributors, the notion of “hiding” the content editing and workflow experience from the frontend may not make sense. This could result in a more complex editorial workflow that slows content production rather than encouraging it.
Finally, headless systems sometimes complicate the whole notion of “preview” within traditional editorial workflows. What sense does it make to preview content if you can’t yet tell in what context (or series of contexts) it might ultimately be presented? We’ve already seen a glimpse of this challenge as web CMS vendors tried to deal with responsive design and communicate to content authors that any given “preview” was not all encompassing.
The final word
Taking the above benefits and limitations into account, project teams should closely examine their needs to determine if going headless is the best approach. Headless isn't appropriate for every project, but with the possibilities it does offer, taking the time to outline short and long-term goals to determine if it's an appropriate choice is vital to modern project planning.