You may have heard the buzz recently about Headless CMS and Content-as-a-Service, and wondered whether this approach should be a pillar of your content management strategy. This is a key architectural decision and you should be very deliberate in the path you choose. But before I dive too deep, let us level-set on what these terms truly mean.
What is Headless CMS? And CaaS?
Both headless CMS and Content-as-a-Service are architectural concepts applicable to Web Content Management (WCM) and Content Management System (CMS). A CMS typically provides a set of content management capabilities that enable you to define your content types (such as press releases, announcements, job postings), author content articles, categorize and tag content, define the site navigation, preview content, allow for content approval workflow, manage documents and media, and so on. Additionally, most CMS products provide a full set of site and content rendering functionality that allows you to compose a website using out-of-the-box applications so that you do not need to build this functionality from first principles. In a CMS the content delivery piece is considered the head.
A Headless CMS approach is one where you use the CMS product’s content management capabilities and content repository, but roll your own content delivery functionality using the product’s content access APIs – in other words, you cut off the CMS product’s head – hence ‘headless’. Examples of market-leading Headless CMS products that we love at XTIVIA include Contentful and Strapi.
A Content-as-a-Service (CaaS) approach is one where you expose content via APIs (typically REST or GraphQL) and leverage those APIs in your applications (websites, mobile apps, web / enterprise applications, marketing tools and more) to consume and render the content as desired.
A headless CMS approach implies that you will use the CaaS APIs to build the ‘head’ – in other words, a headless CMS dictates usage of CaaS. On the other hand, CaaS does not imply headless CMS and can be used in conjunction with a CMS implementation wherein you use the CMS product’s built-in content management and rendering capabilities. Typically, you may use the CMS product’s built-in capabilities for the web channel, and use its CaaS APIs in a custom mobile app to retrieve and render content.
One other point about headless CMS is that this concept is also applicable in modern Digital Experience Platforms (DXP) where you may choose to use a DXP in a headless manner as well.
Advantages of Headless CMS
Now that we have a common understanding of the two concepts, let us consider why you might consider going ‘headless’. Typically, this comes down to one or more of the following reasons –
- You have a number of “heads” – websites, single page apps, mobile apps, IoT, wearables, and more.
- You want the freedom to use your preferred UI technology such as a particular flavor / version of Bootstrap or a JavaScript technology such as Angular or React, rather than being limited by what is used by the CMS product (in fact in early days of responsive web design, your CMS product may not have supported it for quite some time leaving you in a lurch). With the headless CMS approach you can work around any UX/UI limitations – if you can dream it, you can build it. This is typically the number one reason why most folks adopt the headless CMS approach.
- You can achieve seamless integration between content and application type functionality – often when building a website using a CMS you may have website pages that combine content with functional applications, and if you use the CMS product’s built-in content rendering functionality, you end up having two different JavaScript frameworks / libraries in use on that page impacting the overall user experience. With a headless CMS approach, you do not face such limitations and can achieve a completely seamless experience where an end user cannot tell any difference between content and custom functionality.
- You want a layer of abstraction between your end-user facing application and your chosen CMS product. In other words, as a business or architectural principle, you do not want to tie yourself too closely to the CMS product. By custom building your content delivery ‘head’, and having that tie into the CMS product via its APIs you give yourself the flexibility to swap out the CMS product in the future without impacting the front-end content delivery application.
- You want to use a particular CMS as a content management back-end in combination with another DXP, CXP, Portal or CMS product that you wish to use as the “head”.
Disadvantages of Headless CMS
These can be powerful reasons that swing you in favor of the headless CMS direction, but do keep in mind that these advantages come with their own costs / cons that include –
- The most obvious one is that you are not fully leveraging your investment in the CMS product by utilizing all its capabilities if you are using a traditional CMS/DXP in a headless manner – in particular, the content rendering pieces, and you are in fact incurring additional costs in custom building and maintaining these pieces. The key cost is in the long-term maintenance of the custom content delivery components as the Content APIs may evolve as time goes on and new capabilities are added.
- Additionally, while you do have a layer of abstraction between your end-user facing application and your chosen CMS product, you are still heavily tied to your CMS at the API level, and swapping out the CMS product is not going to be free or painless.
- Depending on your use case, you may need to protect or secure content – if you build your own content delivery piece, you take on the responsibility to develop, test, and maintain this functionality while ensuring appropriate security.
- A modern CMS or DXP provides various tools to site and content managers that make it easier for them to build and verify interactive sites; some examples of these capabilities include –
- Ability to compose site pages using drag and drop of various out-of-the-box components that allow rendering content lists, articles, tag clouds, category filters, navigation and more.
- Ability to view their changes in context of the end-user experience including content previews and staged sites
- Ability to impersonate end users and see what an end user sees
- Ability to simulate various user personas / segments and device types
- When you go headless, you lose all these out-of-the-box capabilities and are forced to either limit the tools available to your site and content managers or you have to get into the plumbing business of having to build and maintain all these tools (thereby making you less agile).
- An important con in today’s age of hyper-personalization is that you will be limited in using your CMS / DXP product’s user audiencing and content targeting capabilities. Some of these products provide very sophisticated tooling to make it easier for you to run complex, hyper-personalized campaigns. However, if the CMS / DXP does not own the full context (the URL and the full user request (browser session, cookies, etc)) in the headless CMS approach, then you are either limited in your ability to leverage hyper-personalization or risk running into significant performance issues.
Summary
All in all, these are some caveats with the headless CMS approach and you should not adopt this lightly. Often Enterprise Architects get carried away with implementing pure architectural patterns and don’t necessarily consider all the financial and agility costs of a given approach that is near and dear to their hearts. If you do not have multiple heads, then most CMS and DXP customers are better served leveraging their chosen platform to the fullest extent possible (within limits of how tied you want to be to this platform) and the headless CMS option is not the way to go for them – however if you truly need the UX/UI flexibility that headless CMS offers and you have the team to support this approach, then a headless CMS might be right for you.
At XTIVIA, for the Headless CMS approach, we like Contentful and Strapi, and for the full DXP suite approach, we like Liferay DXP. If you need help picking the right architecture and product for your needs, please contact us for a consultation with our CMS/DXP experts.