Drupal headless part 2

For some time now, there is a new hype in CMS (Content Management Systems) land: it's called “headless” or “decoupled”. In our previous blogpost, we elaborated on the concept of headless and why it is, in a way, similar to your phone charger. In case you haven’t read it yet, you can find it here. In this post, we will dive deeper into the different forms of Drupal headless and give some insights in how to choose the best solution for your organization.


Innovation in content management has been accelerating at a fast pace. This development is mostly driven by both the number of channels that CMS systems need to support (web, mobile, chat, …) as well as the need to support a multitude of (emerging) front-end frameworks. As a result, we have seen headless or decoupled architectures emerge. They exist in basic forms, such as for a website only, and in complex environments such as micro service driven architectures.

Based on the needs of your organization and your project, there are multiple, established ways of decoupling Drupal. Now, we will elaborate on the three most common ways of working with Drupal.


Headless 2

Different forms of Drupal 

1. Traditional Drupal
Also referred to as coupled or monolith Drupal

In this approach, Drupal is used in its default form for a website. It includes default libraries such as jQuery. Drupal maintains complete control over the presentation and data layers. 

A traditional Drupal setup remains an excellent choice for content editors who need full control over the visual elements of their website, with access to features such as in-place editing and layout management. In short: Drupal as we have known it all along. This is still how most new CMS projects are being built these days. 

2. Progressively decoupled Drupal

In this case, Drupal is used for initial rendering with JavaScript on top. If you want a page or component of a website to be highly interactive, you might want to consider rendering the component in JavaScript.  Frameworks like Vue or React are perfect for the job. This JavaScript might be responsible for nothing more than rendering a single block or component on a page or it may render everything within the page body. 

The progressive decoupling paradigm lies on a spectrum; the lesser the page is dedicated to JavaScript, the more editors can control the page through Drupal's administrative capabilities (as is the case in a traditional approach). 

We can consider “progressively decoupled” as the direction most organizations are going in. It is an intermediate state, which is not dramatically different from the traditional way of working. 

3. Fully decoupled Drupal

Last but not least, we have “fully decoupled Drupal”, which is used as a content repository accessed by other consumers, or as a data source. This is a true headless approach. Fully decoupled or headless Drupal implies a full separation between the presentation layer (front end) and all other aspects of the CMS. Both are completely decoupled from each other.  

In this scenario, the CMS becomes a data provider, and a JavaScript application with server-side rendering becomes responsible for all rendering, communicating with Drupal via web service APIs. It is important to note that key Drupal functionalities, such as in-place editing, and layout management become unavailable. Fully decoupled is appealing for companies who want greater control over the front end (in frameworks such as Angular, React, etc.) or where centralized content or data is consumed by multiple applications, each with a specific focus. 

Now that we have a good understanding of the different forms of Drupal, we can evaluate which one suits our organization best. All will depend on the goals, needs and specifics of your organization and projects. 

The best fit

Let’s say you want to build a single standalone website. The choice you’ll have to make, will be completely dependent on the specifics of your organization and features you see as must-haves. 

For example, if you want to build a component-based website, without any crazy front-end features and with maximum flexibility and independence for content editors, headless might not be the way to go. The benefits will not outweigh the limitations. 

On the other hand, in the same scenario of a standalone website, you might want full flexibility in the front-end experience. Maybe your front-end developers don’t really know Drupal. Then decoupled suddenly becomes a valid option. 

If your intention is to build multiple experiences (one of them is a website or web application), you can use a decoupled Drupal instance either as:

- A content repository without its own public-facing front end, or
- A traditional website that acts simultaneously as a content repository. Depending on how dynamic your application needs to be, you can choose a JavaScript framework for highly interactive applications, or a static site generator for mostly static websites.

If your intention is to build multiple web- and non-web experiences combined (websites, native mobile or IoT applications), you can leverage fully decoupled Drupal to expose web service APIs and consume that Drupal site as a content repository without its own public-facing front-end.

The flowchart below gives guidance in the decision-making process:


Headless 2 flowchart

Regardless of the scenario that fits your organization best, what makes Drupal so powerful is that it supports all of these use cases.Contact us today to explore the many possibilities with our team of Drupal experts.

Get in touch

- Decoupled Drupal in Practice, by Preston So
- How to decouple Drupal in 2019, by Dries Buytaert
December 3 2019

Don't miss out

It's more than digital, it's your business
The Reference is nothing without its customers. Melexis is the stock market-listed global player in the semi-conductor and sensors industry for whom we facilitated future company growth by updating the brand, building the completely new corporate website and giving shape to the use of online channels. Read more about this client.