Ahah! Moments with SaaS Headless CMS

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.

SaaS Headless CMS Custm

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.

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

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: