What is a Headless CMS?

12.06.16   Prasanth Nittala

The “Headless CMS” seems to be getting a lot of attention nowadays. We all are excited to see what it offers and how it would change the content management system landscape. Before we delve into the details of what you need to know about a headless CMS, we should start with a definition. What is a Headless CMS?

Typical content management systems generally perform both the roles of “content management” and “content delivery” aspects of websites. To be more specific:

“Content Management” role – which caters to the administration of content and is site for creators/approvers/translators. This role deals with features such as Content creation and Editing Capabilities, Content Taxonomy, Content Versioning, Handling Content Translation, Content Workflow, handling Security of Content, Publishing capabilities.

“Content Delivery” role – which caters to actual website that is presented to website visitors. This role generally deals with features such as presentation of the published Content, caching of generated presentation, security, personalization capabilities, content preview functionality.

“Headless CMS” systems handle the content management capabilities as to content creation/approval but do not handle the delivery capabilities (hence the word headless if you consider the website as head). They expose content through API’s in a consumable format to build websites/apps with NET, Java, PHP, Node.js, JavaScript frameworks such as React, Angular, native apps on iOS or Android, Tablets and Smart TV frameworks. 

Now that we have seen what is "Headless CMS", we can look into the benefits and challenges of having these systems:

Benefits:

-        This provides for “Decoupled CMS” with the delivery tier separate from the Management tier.

-        These are generally low cost options when compared with huge upfront costs of non-Headless CMS and operate following the Cloud model providing for scalability, availability, and several other benefits of Cloud ecosystem. 

-        These systems are simpler as compared to traditional web CMS’s as their feature set is focused to the management aspect alone.

-        This focuses on the content centric model rather than page centric model.

-        This allows for “Polyglot Presentation” allowing for delivering to multiple channels using multiple programming paradigms.

-        This provides for being able to take advantages of the latest developments in language frameworks and pick and use different set of tools for different channels.

-        This also provides for prototyping and tweaking things as they go along with minimal cost unlike traditional CMS where they have upfront cost.

Challenges:

-        Diverse programming platforms require diverse skill sets in the organization to develop, maintain those systems which is challenging.

-        In the non-headless CMS, generally the same developer is building the functionality and looking into the needs of templates/content/presentation of the content. Now with this separation of the Delivery tier, the Management and Delivery tiers teams need to work together to get desired functionality on the site. Service Contracts play a vital role in this kind of architecture as to the kind of API’s the Management Tier offers and what Delivery Tiers would need. Management teams and Delivery teams needs to communicate about the different needs and not work in silos.

-        Caching of content from the Management Tier would be easier, but caching of HTML markup would have to be dealt with at the Delivery Tier with proper caching strategies. They also need to consider cache invalidation strategies in such case when content gets updated or new content gets created.

-        1-1 Personalization of the websites would become a challenge as the Management tier is decoupled from the Delivery tier and depends on how much data is being shared back and forth between the tiers. This may be alleviated with the marketing platforms such as Monetate, Qubit and others.

-        Content strategy as to granularity of content and the taxonomy of content will play an even more important role in this kind of architecture. Content needs to be created for targeting different platform variations as the amount of display space for mobile versus smart TV varies

-        Security would be another area of concern as to how security is dealt with as there are now multiple systems for incorporating security of content.

-        Some of the CMS packages provide for hybrid approach in which they are having pages but lets you also pull content from other places to show on the page. Hence, they are not totally page centric model and take hybrid approach.

-        Preview functionality which is common in traditional CMS’s is no longer going to be feature of these systems. Headless CMS’s may provide a feature named “Preview” which may be simple display of the content entered in that item as the main goal of these systems is decouple the presentation aspect of the content.

 

Now that we have seen the benefits and challenges, we are able to make better decisions as to how we want to approach these systems and where they can be leveraged. The headless CMS is not a new concept and existed even in the 2000’s, as you can note in one of the below references. However, with so many form factors evolving, and the evolution of microservices architecture, they has gained more popularity. Most of the modern CMS systems do provide content as service and that would alleviate the problem of consuming the content in disparate presentation paradigms. As it stands, this provides more options that can be evaluated based on business needs and capabilities.

 

Other references on this topic:

http://gadgetopia.com/post/252

http://gadgetopia.com/post/7206

http://gadgetopia.com/post/8244

http://www.programmableweb.com/news/cope-create-once-publish-everywhere/2009/10/13

http://ez.no/Blog/Content-as-a-Service-CaaS-Decoupled-CMS-and-Headless-CMS-101