What headless CMS is and how it works

Headless apps, in general, is a relatively new approach, but developers are very often the early adopters for new tools and practices. Moreover, when it comes to content management, especially text content, they have a lot to say. They manage heavy code-bases on a daily basis and the separation of the backend concern from the frontend simplifies software engagement. Read what is the headless CMS and how it works. 

Headlesss CMS explained

Usually, a Headless eCommerce app is a set of backend services—such as CMS, Order Management, Stock Management—and a single, lean frontend application which integrates all the services and features into one coherent user environment. It means that the UI layer can be managed by a different team, utilizing separate skills and technology stacks than the backend technologies. A headless CMS is,  at the most basic level of an explanation, the CMS that makes content accessible only via API for display on any device. It limits the coders' engagement and thus optimizes business growth. 

Read more about headless commerce

The term “headless” comes from the concept of chopping the “head” (the front end, i.e. the website) off the “body” (the back end, i.e. the content repository).

Wikipedia

Separation of concerns

Developers hate WYSIWYG editors. They generate pretty messy HTML reminiscent of that created by MS Word in about 2003. It’s improving over time but a visual editor still equals a lot of additional work. The reason for that, I guess, is that visual content editing does not separate roles enough. 

Front-end developers don’t like taking care of the content details. They prefer to have full control over how it renders, optimized for the user’s device. Editors, on the other hand, use all the tools the WYSIWYG editor provides them with—including styling and formatting, which can cause a lot of trouble.

Modern static page generators start with a separation of concerns in order to provide the content in the form of semantically meaningful documents. The editing process is separated from the render process by some kind of intermediate format which is both easy for a human to edit and easy to process. 

Here are just a few of the most popular intermediate content formats:

• MarkDown language: Popularized by Github, MarkDown looks okay even in its plain form, and can look really cool when rendered. It’s used, for example, by VuePress; and Jekyll;
• WikiText: Started with Wikipedia and is now being used by popular Confluence (Atlassian.com) and GitBook projects,
• JSON: Generated from a WYSWIYG editor (like ProseMirror) or Headless CMS (like Prismic).

These human-oriented formats, as we might call them, have gradually replaced the old XML, RSS and ATOM formats.

Most modern, Enterprise CMS systems like Adobe Experience Manager, Prismic, Storyblok, Contentful and others support JSON as an output data format. This is great for separating the Data model from the rendering pipeline, which is crucial for introducing headless architecture.

Object-based model

For most rendering frameworks, the rendering process is based on components/widgets that are fed with the structural content. There is usually a JSON config file or feed making up the page of a particular component (written, for example, in React or Vue.js). The provided data is injected and the components take care of the proper rendering process.

Rendering pipeline

Typically, the content starts the flow within the WYSIWYG editor where Visual Merchandisers can design the nice-looking pages, as well as managing the blocks and widgets. The content itself is mapped into an Object-based data model. Usually, each visual block/widget is represented by a single JSON data object.

The rendering pipeline is then fed by the GraphQL or REST API with these JSON objects that are then mapped to the JavaScript components (React, Vue, Angular) that contains all the business logic required to render the content - optimized to the device.

Real-world example: CMS integration in the Shopware PWA project

Since October 2019, we’ve been working together with Shopware AG on a Shopware PWA product. Within that project, we implement the integration of Shopware Shopping Experiences CMS Page Builder with Alokai .

Content such as Category Layout, Landing Page, and Product Page can be created in a WYSIWYG Editor named Shopware Shopping Experiences.

Each page is made of sections and blocks which are translated to Storefront UI components filled with data right from Shopware instance.

Some example blocks that might be placed within all of the pages across eCommerce Storefront : 

• Product Listing Block 
• Image Gallery Block 
• Sidebar Menu Block 
• Text Block

How to integrate the dynamic data feeds?

The static information managed by the content creators/Visual Merchandisers is one side of the CMS integration. Then you need to figure out the best way to mix this static/marketing content with dynamic data feeds like product listings.

Typically, the dynamic data should be integrated with the CMS itself and then with the headless frontend app to make sure the data displayed to the user is always accurate.

Let’s look at how we recommend integrating product-related information with CMS data for Alokai deployments.

The eCommerce Platform: Product/Category feeds are integrated directly with Alokai components - the renderers. The CMS provides Alokai with static content and IDs/references to dynamic content (product IDs, category IDs) to avoid data desynchronization issues. 

Recommended articles:

• Headless CMS explained in 1 minute
• Headless CMS explained in 5 effective minutes
• What is Headless CMS