History of Content Management Systems
Content Management Systems as we use them today go back to the times when the Internet was invented by Tim Berners-Lee in 1990. Data and Content had to be stored somewhere — and even more important — had to be maintained and updated. Initially, most contents were created like documents, edited, and stored as static pages. This is enhanced with the need for dynamic content, interaction like commenting, or linking.
This came with some problems as to how HTML is used, contents were only available in one format, and the source was created on a server that did not know anything about the device it was rendered on. With upcoming Mobile, but also other IoT devices it was hard to render this content appropriate on all devices.
What does this mean?
While the content was rendered into a unique layer of HTML on the server-side, only CSS was able to design this output. There was a hard binding from Content to HTML. This caused less flexibility and relaunch. Or re-using of content created effort in re-creating the server-side rendering. CSS could always re-create new designs with existing content if HTML is written properly. (Examples like CSS Zengarden are showing this for decades) But this heavily depends on semantic Markup and no Elements used that cause already design (like line breaks, <div> containers that represent design or similar).
Nowadays we can adjust layout and design with CSS and Media Queries. There were times when browsers were not supporting this well.
How do traditional CMS monoliths work?
A traditional CMS is a software that you either install and manage yourself or in a managed server environment. Traditional CMS is also known as “monolithic” because they contain all functions and assumptions for working in a single system. Traditional CMS often offers a visual authoring interface for editing content (WYSIWYG), as they only have one context for displaying the content — usually a website. The system normally offers a direct editing layer on an existing rendered layout.
The headless CMS only contains a data layer and authoring. They provide an API for a headless rendering layer that consumes the data. The aforementioned is also one of the challenges. How can you render a WYSIWYG experience when your authoring system does not know about the rendering?
A new generation of CMS were invented. These often offer additionally Headless on existing systems, like CoreMedia for example, where besides Freemarker Template, a Headless GraphiQL server exists.
How to consume headless data
Headless also provides the possibility to get a content hub to ensure “Content first” implementation. Your one base of content will be able to maintain a bucket of additional endpoints.
This data will be consumed via APIs — below are some examples.
Representational state transfer (REST)
REST is a software architecture style that defines how to create web services. Web services, which conform to the REST architectural style and are known as RESTful Web Services, provide interoperability between computer systems on the Internet. RESTful web services allow the requesting systems to access and manipulate web resources using a set of stateless operations.
GraphQL is a query language for your API. Also, a server-side connection for executing queries belongs to a type of system to use for your data management. GraphQL is not tied to a personal database or storage engine and is driven by hidden code and data management.
A GraphQL service will have types and fields for those types. There are functions for each field from each type.
This is the rising star, as it offers flexibility not known before.
I mention GROQ though it is not really widely used, but as I see similarities to GraphQL worth sharing.
Where headless helps:
- Your team is familiar with a special UI Technology.
- There is a need for A/B tests
- If you require a client-side rendered Framework like VUE, React, etc
- Personalization of Content
- If you have static side generators in place (Gatsby, Jekyll, Middleman, Next, Nuxt, or Eleventy)
- Mobile Apps or IoT
- If you need to enhance your E-Commerce data.
Drawbacks and Challenges
Editing your content can be harder for authors on headless systems. Your System is depending on a second screen/system.
Websites created with traditional CMS, allow customizable zones, and authors can resize and rearrange dynamic content easier. They are not limited to edit dynamic data in a fixed zone. They are enabled to share content easier.
With headless, authors often can’t customize the placement or presentation much beyond given forms, without implementing configurable content grids. Dragging and dropping components is getting harder, as the components only exist as data and rely on a presentation layer.
It can be more expensive to implement and the share of costs can get more complicated when only one unique source exists, but multiple layers consume it.
There is no black and white decision possible. It depends on your team’s skills, your client’s or customers‘ needs, your project setup, and so on. Just make the right decision in the beginning.