Decoupled CMS: The Onslaught of the Headless

To understand why a system is referred to as headless and the advantages it gives, we need to examine the design of traditional non-headless systems. They were mostly monolithic with all features under a single code base.

One of those features would be theming – a presentation layer that could be extended and overridden to produce the look and feel desired. However, this was deeply coupled with the internals of the system and many things were difficult. For example, you could change presentation code all you wanted but changing the ordering of that code meant changing some configuration files. In some cases you had dependency issues – you could not render one thing until another had finished rendering due to a side effect it had. When changing content you frequently needed to return to the server and render the entire page again with the new content. These problems can hinder advanced interface design and slow a user’s experience.

List before filter or filter before list?

Magento 1 has a perfect real world example of complex coupling that hinders innovation on the interface. When rendering a category page product list, the filters sidebar and the toolbar had to be rendered first. These would load the filters and pagination and at the same time (presumably for optimisation reasons), it would apply those filters and the pagination limits to the product list so that when it renders it does so with the correct page and products. Move the product list to before the filters and toolbar and you now have an unfiltered product list with no pagination – the filters and pagination hadn’t been rendered yet to do their thing! Here the architecture has a direct impact on the presentation layer. (You might be wondering – why would you place the list before the filters?! In our edge case we were required to add information about the product list results to a block in the header and in another case render previous/forward references for search engines – both cases needing the product list before the filters and pagination were rendered.)

What is headless CMS?

Decoupling has been a design principle for a long time in development. Headless is where we apply this decoupling to the presentation layer itself, freeing it for extreme innovation with the use of REST APIs. A headless system exposes all functionality across a range of APIs so that developers can integrate their interface with it seamlessly.

Advantages of a CMS decoupled

There are many advantages to a headless CMS, giving you more freedom from imposed restrictions and enabling developers to innovate with the skills they have already honed:

• You no longer are tied to a front end framework by the CMS (Magento 2 gives you tightly coupled LESS and Knockout), meaning you can now build innovative interfaces on React, Vue, Angular and the likes with no implied restrictions.
• Your developers no longer need experience in the intricacies of the systems providing the data – if they are developing in React that is the only skill they need to develop.
• Launching an app for your users? The app developers now have the ability to built an innovative, native interface to your super content management system – a single content source for all channels!
• Have multiple headless systems? Integrate with them all from one interface! (This last one is my favourite – a true hybrid approach to use the best of the best for all your user needs whilst exposing a single recognisable and uniform experience.)

The advent of headless ecommerce

As of writing, Magento has announced the launch of a React based interface, Magento PWA Studio, that will use Magento 2.3 as a headless ecommerce platform. WordPress has a complete API. Drupal 8 has also had a large API since it’s early stages. There’s many more to boot!

Headless systems let you pick your challenges and concentrate on what matters most to your users – their touch points with your brand.