Are you familiar with the potential of a decoupled CMS? Let’s understand what it is, when it makes sense to use one, and what the features of Drupal headless are — one of the most mature solutions on the market.
What is a headless CMS?
To understand what “headless CMS” means, we first need to consider the starting point: the model traditionally adopted for building websites. In this case, the web page is statically generated by the server. In practice, the user makes a request to the server by typing the site URL into the browser, the server receives this URL, generates an HTML page, sends it to the browser, and the user views it.
How does this change when we use a headless CMS such as, for example, Drupal headless? In this case, the page logic is largely built on the frontend rather than the backend, which is used only as a data source.
In the case of an online newspaper website, for example, the backend is the source of the content — the articles. When a user opens the site’s homepage, the page they see is an empty container where the frontend, through a request to the server, loads the content and displays it according to the logic that has been set up.
In effect, using a headless CMS means separating the backend and the frontend: by doing so, the CMS (backend) remains “headless,” meaning without the head (which corresponds to the frontend, now in the browser). This is also why we refer to it as a decoupled CMS — “decoupled” indicating the separation of a pair (backend + frontend) that has traditionally been inseparable.
If we wanted to give a concise definition, we could say that:
A headless CMS is a backend-only content management system built as a content repository that makes content accessible via APIs for display on any device in an omnichannel approach.
Headless CMS: what needs do they meet
The headless approach was born to meet some concrete needs increasingly felt in the modern web, from aesthetic to performance requirements. A few examples:
- Improving the UI by enriching pages with animations, dynamic elements, and impactful graphic solutions — all without excessively slowing down element loading — by leveraging the capabilities offered today by frontend frameworks such as Angular, React, and Vue.
- Decoupling integrations with external services, which are increasingly common today. Think of content feeds from third-party sources like social networks, or social login via Facebook or Google, to give some intuitive examples.
- Loading the page progressively rather than all at once. Going back to the online newspaper example, it’s easy to imagine how heavy a homepage could be when it has to load hundreds of articles.
Achieving these goals using a traditional approach could be inefficient, especially on web applications with very complex frontend logic. In the headless model, instead, the server handles the content while everything the user needs to view the page is progressively built at the browser level, thus leveraging the computing power of the device in question.
Headless Drupal, one of the best headless CMS options
Drupal has historically been widely adopted by content-driven sites for its flexibility and the advanced content workflow management tools it offers (we discussed the advantages of Drupal here). It is now clear that these are exactly the types of websites that benefit the most from a headless architecture.
It comes as no surprise, then, that Drupal in recent years has worked to create one of the best headless CMS options currently available on the market. The API-First initiative, launched in 2016 to coordinate the development effort and enable Drupal to be a fully headless CMS, is particularly significant in this regard.
We can consider Drupal one of the most mature headless CMS options because it includes in its core most of the features required for headless. In particular, we are talking about REST API and JSON:API.
The great advantage of headless Drupal lies precisely in the fact of having these modules in the core, supported by the community and by core maintainers. Tested, stable modules with well-documented standard paradigms, ready for production.
By combining Drupal with a JavaScript frontend framework such as Angular, React, or Vue, it is possible to maximize the advantage gained: on one side a powerful backend, on the other a frontend ideal for creating a sophisticated UI rich in interactions.
YOU MIGHT ALSO BE INTERESTED IN: Drupal 9, why and how to upgrade
REST API and JSON:API
As already mentioned, there are two main ways to go headless included in Drupal’s core: REST API and JSON:API.
The RESTful module in the core has been available since Drupal 8.2. It allows easy interaction with all standard entities available in Drupal (nodes, users, taxonomies, comments).
The JSON:API module was made available starting from Drupal 8.8: it is therefore a more recent standard, conceptually very similar to REST API but designed specifically for the headless model.
The conceptual difference between REST API and JSON:API is that the former provides a specific response to a specific request, while the latter is designed to describe the entire page. In the headless context, this approach is ideal: the frontend can request a description of the entire page from the backend, rather than requesting each individual page component (as happens with REST API).
For a more in-depth comparison, we recommend this Drupal resource.
Advantages of headless CMS
Better performance
The server of a site with millions of visits every day receives just as many requests and risks not being able to respond quickly. By decoupling backend and frontend, it becomes possible to offload the server, distributing the effort to users’ devices: this way, the server response is virtually immediate. This results in faster navigation for the user and therefore a better user experience.
The performance improvement is not only useful from a user perspective but also from an SEO perspective: think, for example, of LCP (Largest Contentful Paint), a metric that measures the loading time of above-the-fold content, and which since May 2021 has been one of Google’s main ranking factors. It is therefore essential that the first elements of the page are loaded as quickly as possible.
Managing multiple frontends
Many companies need to manage more than one frontend to bring an omnichannel strategy to life: one or more websites, mobile applications, web apps, widgets, smartwatches, PlayStation, etc. We are dealing with different frontends that nonetheless share common content, manageable from the same backend thanks to a headless CMS.
The savings in time and cost are easy to envision and concern both development (one backend instead of several backends) and content management, which is faster and simpler because it is centralized.
Third-party integrations via the frontend
We mentioned that headless CMS solutions were also born to address the need for easy integration with third parties via APIs. With a decoupled CMS, it may not be necessary for the server to communicate with the external service to perform these integrations: the browser can handle it directly via JavaScript, offloading the server from this responsibility.
The ease and speed of integration opens the door to various user experience opportunities: from Instagram or Twitter post feeds, to social login, to advertising integrations, analytics, and content embedding. Even login access to restricted areas of Cloud Native applications today should follow standards like OAuth, which once again allow us to integrate the frontend without necessarily redeploying the backend.
Better time-to-market
Choosing a headless CMS makes it possible to parallelize backend and frontend work, employing the entire team within the same timeframe.
Developing a complex site using the traditional approach requires the initial phases of work to focus on the backend. During this period, frontend developers cannot work on the project, and furthermore, it is not possible to have a “visible” output to validate. This is an inefficiency that the headless model resolves: the frontend can start working on the page styling, taking for granted that when the backend is ready, it will provide the requested data according to the agreed-upon standard.
By doing so, even though the number of “person-hours” doesn’t change compared to traditional development, it is possible to reduce time-to-market by making the development process more efficient and bringing forward intermediate verification and output validation milestones.
Ease and speed of modifications
The decoupling of backend and frontend is an initial iteration of the Cloud Native approach that involves splitting the project into numerous independent microservices. We know that having many separate services, as opposed to a single monolith, makes it easier to implement targeted modifications to individual services without impacting other parts of the application.
With a headless CMS, we have a similar logic: if a specific intervention on the frontend is needed, there is no need to make changes to the backend — it is enough to deploy the modification to the frontend.
The advantages of this capability are seen at the level of:
- Cost and user experience: targeted and faster modifications;
- Uptime: there will be no downtime related to site maintenance or updates.
Resilience and updates
In a non-headless site, what happens if a new standard for Drupal or PHP comes along? This eventuality often entails the need to rebuild the site: a significant cost but potentially also a period of downtime.
This challenge can also be reduced thanks to decoupling. In many cases, having a headless CMS can allow you to modify just one piece of the infrastructure while the rest remains fully operational. Working with standards (REST API and JSON:API), when changing the Drupal version or PHP version, we can be reasonably confident that the standard is respected and that the frontend will continue to work.
It thus becomes possible to react to issues and market changes more quickly.
Challenges and requirements of headless
Adopting a headless CMS, like any technology, is not without its challenges.
This approach certainly increases the complexity of the application because it involves creating and maintaining two applications: the backend that generates content and the frontend that reads it. In strictly technical terms, this means having two deploys, two pipelines, twice the tests, and potentially twice the containers. As complexity increases, the risk of error-prone components also increases.
Another consideration, which is not necessarily a disadvantage, is that the development team must be multidisciplinary; it must therefore include both backend and frontend developers. For companies organized differently, this may require an investment in new specialized roles.
Should my company choose headless?
To conclude, the choice of a headless CMS is recommended for content-driven sites because it allows managing large amounts of content from a single backend without compromising user experience. In this regard, headless Drupal represents one of the most mature and efficient solutions for decoupling backend and frontend thanks to secure and tested standards, available in core modules.
In the case of a brochure website that is rarely updated or a simple landing page created to promote a product, the headless approach certainly makes less sense, and a traditional CMS could be the better choice.
