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.
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
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.
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
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:
Get in touch
- Decoupled Drupal in Practice, by Preston So
- How to decouple Drupal in 2019, by Dries Buytaert