Headless CMS explained in 30 Sec
What you need to know about headless CMS.
Written by Vegard Ottervig on
What you need to know about headless CMS.
Written by Vegard Ottervig on
A headless CMS separates the presentation layer from the content repository. To sever the tie between content (body) and presentation (head), the content must be structured and thus compatible with multiple clients and technologies.
Implicitly, the content becomes reusable, potentially being presented differently on different clients. Developers can build websites and applications using their favorite tools and front-end frameworks, and use the headless API to fetch content—with presentation being handled locally.
See us explain headless CMS in 30 seconds:
Headless CMS has become such a thing the last few years because it greatly pleases developers. Initially, the headless approach catered to building native apps, but later technological innovation in e.g. front-end frameworks have widened the headless scene. Developers want to use their preferred front-end framework when building apps or websites, and together with a headless CMS it’s easy to get their project started.
As most headless vendors are cloud-based, it’s also fairly easy to grow with new and evolving requirements due to the flexible and scalable architecture and pricing models.
Additionally, a headless CMS integrates well with design systems built using front-end frameworks, letting you achieve a consistent look and feel across your digital experiences.
Headless is all about flexibility. You are not locked into a CMS specific programming language or templating engine anymore, hence you can build front-ends and solutions using various frameworks and technologies that can fetch and process content in the form of raw data.
As the front-end of your website or app is decoupled from the content repository, it is easier to make adjustments and redesign solutions without interrupting business users who simultaneously create and manage content.
When you are liberated from back-end structures and forced couplings between content and presentation, you are free to focus on building even richer digital experiences for the end user. At the same time, editors can concentrate on creating the best possible content, and not worry about how it will be presented in different channels.
The decoupling of CMS and your own implementation often means upgrading your CMS will be easier. As long as the API is backward compatible, you can upgrade the CMS without changing your clients—and visa-versa.
We will split the challenges in two, one set for developers and another for content editors. We start with the developers:
Even though the headless CMS in itself can be more lightweight and faster than a traditional CMS, that complexity is shifted over to the developer, which now has to deal with issues that were previously out-of-the-box from the CMS, resulting in larger projects and code base. Earlier, coding was “predictable” as you were building directly on the CMS. With headless CMS, you technically start off with an integration—just to make a simple web page.
Accordingly, the developers must take more responsibility for the project. You must build and maintain a larger code base, as fewer things come ready-made. You must also deal with rendering logic, routing, and templating.
Moreover, you will need to deploy and host code for your front-end (and additional back-end logic) in addition to the CMS. This might lead to more work than previously, when a sizable portion of the code was intrinsic in the CMS itself. Hosting your custom code also means taking responsibility for security and scaling.
Many headless CMS vendors are cloud-based, which means convenience, speed, scalability, and security on the one hand, but less control on the other. If the vendor uses a SaaS approach, where most customers are continuously updated, this also means the provider may roll out “forced” updates to the user interface and APIs, even at times when it might not suit you.
Challenges for content editors include:
Given that a headless CMS is essentially a database + an API, editors that are used to visual landing page editors may be in for a surprise. When forms are the fundamental editing blocks, users can have a hard time building landing pages and handling larger structures. Vendors that actually deal with this problem are now starting to emerge.
With no tie-in to a front-end, the content might not always have a meaningful preview. Developers can integrate a preview or create a default, generic preview, but preview tends to be cumbersome and may not take in the full context.
Most headless content management systems do not provide a tree structure to enable structuring of your content to reflect a website. Hierarchies may also be useful for management purposes, since you can make a logical structure based on teams, departments or similar—for instance to apply more granular user permissions and access control. Consequently, without such a hierarchical organization, the URL management will likely be a chore as well.
Most of the mentioned headless CMS challenges can be overcome with the adoption of “hybrid CMS.” Hybrid offers a headless CMS with extended capabilities for back-end customization, where you can develop and deploy code to customize APIs, run scheduled tasks, and other integrations. As such, it is a tighter and more integrated platform, with less code to manage.
Although it separates data and presentation logic, a hybrid CMS is still delivered with an optional presentation framework to reduce developer complexity and please content editors. There are big differences between vendors in this field. Some offer a more traditional approach, where the headless API is added as an afterthought. Be sure to assess vendors thoroughly in your search after the best hybrid CMS.
What lies in the future for headless CMS? We can see a tendency where first-generation headless CMS shortcomings are leading to the next-generation of headless offerings. Vendors are now attempting to broaden their solutions, thus making them more complex.
Contentful serves as a case in point. Starting out as a pure headless CMS, their later forays into traditional page building with the Compose app serves as an apt demonstration. Headless vendors now aim to solve problems that “old school” CMS vendors have historically excelled at. Contentful’s solution now becomes an afterthought, resulting in a more complex editorial experience and losing the lightweight benefits of their initial offering.
Some vendors, however, seem to solve both challenges: the headless approach for developers and a good user experience for editors.
First published 23 March 2022, updated 6 September 2022.
Get some more insights 🤓