Headless Thinking

Understanding the Terms

Switching to a headless content management system is a nexus of change in any organization. While the implementation of a headless CMS is rather simple and can be integrated within a few hours to any existing technology stack, the paradigm shift in how we treat content in the modern stack is monumental.

A New Lexicon

Let's look at some helpful definitions that you will encounter through the documentation, tutorials, and examples.

Headless CMS
A term used to refer to an API centric content management system where there is an absence of templating features. In the purest form, a headless CMS simply allows you to read and write content via an API. Reducing content to a primitive.

Hybrid CMS A hybrid CMS attempts to blend both the headless and the traditional CMS by offering templating features as well as an API. Highly prescriptive content structures.

Monolithic CMS A traditional content management system that encompasses everything from content management to templating language. Highly prescriptive development style and content structures.

A New Way to Think About Content

In terms of interface for editors, not much has changed. Users log into an application, are provided with a user interface and they can create, update and delete content in traditional formular style. The largest mental model change is regarding how we think about the consuming context of our content; namely, we don't think about the context. The greatest danger in the traditional CMS methodology is to collocate display logic with our data models because we retain a notion of "where" that content will be consumed.

Modern application targets are no longer web-only and quite often not even web-first in their consumption. Freeing our content from the notion of "where" it will be consumed allows us to write content in the purist data structure possible. In contexts where some degree of editorial oversight is still needed, we encourage the use of relationships to create a new data primitive that represents banners, widgets, layouts or whatever else may be needed for the project. This "wrapper" data structure can then be targeted by an opinionated context without the need to pollute our data source with loosely related content.

A simple rule of thumb when defining our data structures, only include data that is an inherent truth of the data model.

Content Structure Examples:

Bad

{
  "type": "image",
  "description": "A bear on a tri-cycle",
  "align_mobile": "left"
}

Good

{
  "type": "image",
  "description": "A bear on a tri-cycle",
  "area_of_interest": "right"
}

Planning for the Future

When we remove prescriptive paradigms from our content, we open up the opportunity to re-package our content for numerous other applications. While many companies and businesses find that their immediate need for the next quarter is simply getting a website online, thinking of content as a modular component to be integrated with any stack allows for freedom of technology choice, flexibility for changing deliverables and opportunity for compelling new targets.

When you stop shipping compiled HTML over the wire, you can now realistically look at mobile frameworks, audio devices and more with a very real "go-to-market" plan and the ability to begin development immediately without onboarding a new editorial flow, aging technology framework and more.