This blog post attempts to list some of the main learning points that I have encountered while transitioning from legacy to headless CMS. If you know of additional significant learning points in the headless journey (including SaaS and service-oriented architectures in general), please comment on this blog post.
I should mention that this is about SaaS headless CMS, because without SaaS, you’re not getting the value of headless.
Headless Really Means Bodyless
Headless means that the CMS does not provide a content delivery engine, only content management and content delivery services (the body). CMS customers implement content delivery solutions (heads) that access content delivery services (the body). Headless CMS vendors have no knowledge of or responsibility for the heads. The CMS is headless to the CMS vendor, but is bodyless to the CMS customer, who has no responsibility for managing the content management environment.
There Is No Platform, Only Services
A SaaS headless CMS is a platform, but you do not build solutions on top of it. You build your own platform and your solutions next to the CMS, not on top of it.
The CMS Is Just a UI for Editing JSON
Headless CMS products focus on a single domain: managing content. The CMS is simply a UI for editing JSON representations of content.
It Really Is That Simple (and Keep It That Way!)
Both architecturally and conceptually, SaaS headless CMS is relatively simple. The CMS is just a black box that exposes a UI, functions, and data as HTTPS endpoints. Do not overcomplicate the solution.
There Are Only Three Interfaces
No matter what you need to achieve, there are only three interfaces to achieve any functionality with the CMS:
- The CMS UI, including extensions and data used to control it
- The underlying HTTPS APIs used to retrieve data and invoke operations
- Webhooks, which send data from the CMS to other applications
APIs are further subdivided into content management, content delivery, and otherwise.
Accept JavaScript and Static Files
Many headless solutions employ Jamstack architectures, making JavaScript the dominant language for both client-side and server-side programming. With possible exceptions, Jamstack architectures deploy static HTML files to CDNs rather than generating HTML on the server at runtime. Web developers seasoned in other technologies may need to refocus on JavaScript, JavaScript frameworks, and server-side JavaScript environments.
The API Is the Enemy
As headless systems intend to decouple systems, then use of any CMS SDK, API, or vendor-specific data format is against purpose. When implementing headless CMS solutions, it is impossible to avoid accessing APIs and using vendor-specific JSON formats. Address this conflict with solution architecture. Minimize, centralizing, and abstract API access, preferably calling APIs directly rather than using SDKs. Normalize data out of vendor-specific structures at this level. Where possible and appropriate, export data to your own independent systems including search rather than accessing vendor platforms directly.
- Avoiding Direct Headless CMS Service Access – Deliverystack.net
- Centralizing [Headless] [CMS] Data Access – Deliverystack.net
- Working with [Headless] [CMS] Vendor [.NET [Core]] SDKs – Deliverystack.net
There Is No Native Hierarchy
While this may not be true for all SaaS headless CMS systems, it is true for Contentstack: there is no native hierarchy to content entries, such as the directory structure on a file system. At least in Contentstack, in the CMS, entries are grouped only by their content type, with various types of implicit, explicit, and indirect relationships.
Mapping URLs to Content Entries
In most content delivery solutions, each URL corresponds to an entry that contains data about the page to render at that URL. Content delivery systems must determine the content entry associated with each incoming URL. Different systems use different techniques to determine the URL of each content entry and to determine the content entry associated with each requested URL.
With headless content management systems, the URL of each content entry is often stored as the value of a field in that entry. Static site generators can iterate entries in the CMS and create files at the paths specified in the URL field. Alternatively, or in some cases additionally, server-side and client-side applications can query the CMS for the content entry associated with a URL. Some applications ignore the URL field and use entry identifiers or other criteria to determine the URLs of content entries.
Regardless of how the solution determines the URLs of entries, with static site generators, entry URLs correspond to file paths, and the web server or CDN serves the file corresponding to the visitor’s requested URL. If you use an application, then it can retrieve the entry with the requested URL from the CMS.
Integrate at the Front End
Some CMS products allow extensive customization and development to support integration with other systems. SaaS headless CMS do not allow back-end coding or customization. All customizations consist of a combination of APIs, webhook listeners, and CMS UI customizations. Whether from the CMS or from the published website, integration occurs at the front-end using services for anything that requires back-end systems.
Additional Links
- The Headless [CMS] Metaphor – Deliverystack.net
- Considerations for Migration to Headless CMS – Deliverystack.net
- My Headless CMS Philosophy – Deliverystack.net
- SaaS Headless CMS and Service Oriented Application Objectives and Advantages – Deliverystack.net
- Making the Transition to SaaS Headless CMS and Service Architectures – Deliverystack.net
- SaaS Headless CMS Fundamental Concepts – Deliverystack.net
- Differences between Decoupled CMS and SaaS Headless CMS – Deliverystack.net
- Differentiating Headless CMS Products – Deliverystack.net
- CMS Content Modeling Considerations and Resources – Deliverystack.net
- Evaluating [SaaS] [Headless] [CMS] Data Modeling Capabilities – Deliverystack.net
- [Hard] Questions for [Headless] [CMS] Vendors – Deliverystack.net
- Considerations for Headless CMS Architectures – Deliverystack.net
- SaaS Headless CMS Architectural Considerations, Part II – Deliverystack.net
Deliverystack.net 