A headless CMS (content management system) is a back-end-only version built from the ground up as a content repository that makes content accessible via a RESTful API for display on any device. It is designated ‘headless’ because it does not have a front-end. A headless CMS is focused on storing and delivering structured content.
What started on October 29, 1969, with ARPANET (under the US Department of Defence) delivering a message from one computer to another, became the Internet as we know it today. It is the hub of information that’s available and accessible around the globe to everyone. About 60 per cent of the world’s population has access to the Internet and there are innumerable apps, software, distributed systems and smart devices that use it — enabling what was once in the realm of sci-fi movies and stories. The Internet today is one of the most profitable mediums to make money. From small time creators to large Internet companies, everyone depends on the content to generate revenue. This is coupled with analytics to understand what people like, individually and as part of communities, so that the content can be created to suit their tastes and mood.
The need for CMSs
Much of what you experience as the Internet is powered by the information that is stored in back-end systems of the apps that you use today. Internet companies, schools, universities and even governments store information about you to understand your behaviour, share content with you and to function in meaningful ways.
When the World Wide Web became a phenomenon, it allowed people to share information without boundaries. Anyone with a basic understanding of HTML could create Web pages and host them on a website. It was just Web pages initially and when things caught on, we needed something better to create, store and present the content.
This gave birth to content management systems (CMSs), which revolutionised the way we create information, store it and present it to users. The CMSs enabled people to collaborate to create content and share it with others, in an instant. Soon, people didn’t need to understand HTML in order to create and share content, as the CMS evolved to accommodate complex content creation requirements and provided the building blocks to enable collaboration, document management and storage.
As content became king and with more users and complex content, there was the need to ensure that users could access the content whenever they wanted and from wherever they were. The content delivery networks (CDN) evolved to meet this need. The CDNs try to cache the static content as close as possible to the users so that the content servers don’t have to serve the information that doesn’t change much every time there is a request for it.
Content management systems
As the technology moved forward, computing moved from large mainframes to smaller PCs. And the devices just kept getting smaller — to mobile phones, smart devices such as smart watches and digital assistants.
A traditional CMS includes two major components – a content storage and creation/management system that allows a content creator to create, manage and modify the content and content types; and a content delivery system that builds the content and delivers it to the users when they request for content. The former provides the content storage and management, and the latter is the presentation layer that fetches the raw content, and applies styles and the template to compile the final layout and deliver it to users. It is also possible to add more functionality by way of plugins or addons that complement the content delivery with more features such as advertising.
This worked when PCs were the primary devices to consume content. Think of a blog, video blog or even a news site – a traditional CMS ensures that the content writers can push content, collaborate with each other and then, the content gets delivered to users in the right styles and formatting without the creators doing anything about it.
Pure content management
However, content consumption moved from large screens to smaller ones — think mobile phones and smart watches — and even smart devices and digital assistants that do not have a screen. Traditional CMSs needed to now also provide a way to deliver content on these new devices and form factors. This was tackled by adding support for responsive themes that can adapt to any screen size and layout. For devices without a screen, an API layer was added on top of the content storage engine. The apps that run on these devices can call these APIs and deliver the content as needed.
This works but it’s just only a matter of ‘when’ rather than ‘if’, the computing and consumption is due for a change – just like smartphones arrived a little over a decade ago and changed our lives. We are not sure what this change will be and if you follow the innovations in hardware and technology, you are bound to have heard of things like transparent displays, foldable phones and even wall-sized panels.
That’s where pure content management system comes into the picture – a system that can pave the way for any means of delivery on any kind of device with any size or type of display – even ones without a display! Open source developers (and others) have already done that and these systems are called headless CMSs – named so since they do not have a dependency, or a coupling with a presentation layer found in the traditional CMSs. Since headless CMSs store content in a structured format and without any notion about how the content will be consumed or presented to the users, they are considered ‘pure’. Figure 1 illustrates a basic design of a headless CMS.
A number of popular headless CMSs are based on Jamstack (https://jamstack.org/), which stands for JavaScript, APIs and mark-up, and any software that doesn’t have a tight coupling between the server and client qualifies.
However, you will also find headless CMSs that use frameworks or languages other than JavaScript. Jamstack can be used on a variety of operating systems, Web servers, databases, back-ends or front-ends. It provides a higher degree of flexibility, extensibility and scale, as well as a great developer experience.
One thing is for sure — a headless CMS does not include a content-serving mechanism of any kind and that leads us to the following question.
How do I deliver content?
The traditional systems deliver content with their content delivery component. As a content creator, you are limited by their capabilities in this area. Additional engineering is needed to accommodate any other forms of content delivery that you may need. This means that you need to spend time and resources to ensure all your users can get the content in the same consistent way.
A headless CMS is meant to be designed API-first, and it exposes APIs for you to consume and serve the content from any medium.
Some of the traditional CMSs, like WordPress for example, also provide APIs to bridge this gap. But they are designed to be all-in-one solutions, so decoupling the parts you don’t need is not possible. You can choose to ignore them though.
That’s a Catch-22 situation – you either end up wasting computing resources on components you don’t need to run, or you use them as best you can and fork your code to accommodate different consumption mediums.
With a headless system, you gain complete control over how the content stored in it will be used; and you can design a pipeline that doesn’t need to be refactored any time you want to support a new medium for your users, be it a smart watch or an AR system.
If you have run into the challenges mentioned with a traditional CMS, you are most likely using one of the workarounds mentioned as well. If not, you need to start thinking ahead about when you will run into them and how you will address them, starting today.
Leveraging a headless CMS
Headless CMSs not only can be used in places where a CMS is needed but also in other scenarios where you need to store content in a structured and consistent format. Let’s explore this further!
Almost any scenario that you believe requires a CMS is a candidate for a headless CMS too. However, headless CMSs also have uses beyond their traditional content serving functions. If you look at the tech trends of the last couple of years, you might have realised that chatbots, smart devices and digital assistants are topping the charts. These interfaces are powered by the innovation in hardware, NUI (natural user interface) and of course, the content that can be served in a variety of ways.
A good chatbot is powered by state-of-art NLP models, and optionally, with a voice interface that allows it to understand what is being asked in natural language either using text or voice inputs. Once the processing for this task is over, the bot makes itself useful by surfacing the relevant content. This is similar for the digital assistants — in their hardware as well as software avatars.
The content that you consume this way is usually small snippets of information that can be sourced from emails, calendars, third party services such as flight tracking and weather, etc. But other content, such as the witty responses that you get, are best served from a headless content. These aren’t only limited to jokes, etc, but include meaningful content as well.
As an example, consider a food ordering or a shopping portal. These services take a large number of partners and sellers onto their platform, who list their services or products. A traditional approach is to store this content in a NoSQL DB and fetch the content as the UI is being rendered. On a high level, this approach requires that you build an API wrapper that does the following:
Builds a UI to take onboard the partners, sellers, items and services Validates the content before it is saved in the database with the right structure Fetches the content when being served to the users
Add a chatbot or a digital assistant (or a skill) to the mix and you can serve the content on those mediums too if your APIs are designed efficiently. With a headless CMS, you are left with just the work needed for Point 1 listed above, as a headless CMS provides first class APIs to interact with the data and data types so you don’t have to worry about database handling. You can get started with how you will integrate these APIs with your application surfaces, be it a mobile or Web app, chatbot or a skill for a digital assistant.
Strapi (https://strapi.io/) is one of the headless CMSs that I am working with, and it includes a UI to add content as well as user roles and permissions to control access to the content. Ghost (https://ghost.org/) and Netlify CMS (https://www.netlifycms.org/) are others that I have tried out a little bit. You can look at other options at https://headlesscms.org/.
A headless CMS also makes an excellent case for Web apps or websites, even the ones that are a good mix of static and dynamic content. You can front-end your headless CMS with a static site generator such as Hugo or Gatsby, and achieve much greater performance while lowering your computing costs. Static site generators also support plugins to fetch data from dynamic sources such as APIs. This combination offers a number of benefits when used in conjunction with a CDN. Dynamic site acceleration solutions such as Azure Front Door or CloudFront add an additional layer of performance benefits that can further reduce the load on your content repository. A prime example of this scenario is GitHub Pages (https://pages.github.com/) that allows you to host a static website directly from your GitHub repo, free of cost. Figure 2 is a schematic for this scenario. Variations of this architecture can be useful in other scenarios where serving content is part of the solution.
Challenges with a headless CMS
When looking at the reference architecture diagram, it is evident that the lack of a presentation layer in a headless CMS introduces the flexibility to use any front-end. But it also means that you have another piece of the puzzle that you need to account for when deciding on whether to opt for a headless CMS. A traditional CMS covers your Web and mobile bases out-of-the-box with themes to customise the look and feel. To get started with content delivery on a headless CMS, developers will need to build a user experience (UX) for the content. This is also true for the content creators – a traditional CMS includes content creation and collaboration workflows which are non-existent with the other choice. A pure content management system will also be a culture shock to content authors since well-known concepts such as pages and other UI constructs do not exist at all, and a UX for authors will need to be built from scratch too.
So, is it a traditional CMS or a headless one?
Traditional CMSs have been around for a long time, with quite an ecosystem having been built around them. For example, the popular CMS WordPress is estimated to have over a 60 per cent share of the overall CMS market and 35 per cent share of all websites functioning today. One of the reasons is the extensibility and the plugin marketplace this CMS offers to customise it from a simple blog to a full-fledged e-commerce website. With responsive themes and plugins, you can convert WordPress installations to PWAs and push them into the App Store and Play Store to provide a more engaged experience for the users. Drupal is another contender in this domain.
Headless CMSs are a newer breed in the content management space, and they do tick all the boxes for building scalable and extensible content delivery pipelines that can support virtually any kind of device available today and tomorrow. The user experience, though, needs to be built before you can realise the value they bring to the table.
Moving to a headless CMS may not be a straightforward activity and will require planning and effort to transition your workflows and users seamlessly. Before you start planning on this, take a step back and see if your existing CMS satisfies your current and future content delivery requirements. If you see yourself extending your CMS because it does not support certain delivery surfaces that either your business plans dictate you use or you believe your users are moving to, it is time to consider evaluating a headless CMS.
