Facts and Myths about Decoupling Drupal
One of our past clients recently came to us with a question. Their website had been running on Drupal for several years, and they felt relatively knowledgeable about the platform and the lingo that comes with it.
Earlier that day, the client heard a term they didn’t recognize: decoupling. The client heard that decoupling was quickly becoming one of the “it” things to do with Drupal, and they wondered if they should pursue it to stay current with the latest trend.
Let’s answer the obvious question first: What is decoupling?
Photo by Tim Gouw
At its most basic level, decoupling — or operating a “headless” CMS as it is also known — means to separate the back-end of a website from the front-end. In other words, decoupling is when you use Drupal to manage content and then feed data to other systems or channels (via a REST API, or by some other means), that then can display the data using an entirely separate (decoupled) front end system.
For this client, it was readily apparent that decoupling was not the right strategy. But in order to determine if decoupling is right for you, please allow me to present some facts and myths about the approach.
Decoupling allows content to be managed from one location and displayed across several channels: FACT
Drupal’s biggest strengths have always lied in its capabilities and flexibility as a content management system (CMS). Decoupling enables developers to leverage those strengths while making the data within the CMS available to some other system(s) to actually render and display the content.
The data, or content, doesn’t have to only be displayed on a website. It can be displayed across any number of channels – a website, a mobile app, a digital display board, or an IoT device. That means a website, a TV, a smart refrigerator — all of these could collect content from the same place and display it in a different way.
My Drupal site must be decoupled in order to feed content to multiple systems: MYTH
While having a “headless” CMS provides a lot of flexibility, it is not essential to have Drupal be decoupled in order to display the content across multiple systems. There are cases where it makes sense to use Drupal to render the front-end of a site, while also feeding the data to other systems for display by a different front-end and on different devices.
Decoupling will make my site easier to manage, more performant, and SEO friendly: MYTH
This is probably the biggest myth about decoupling Drupal. Drupal 8 is a powerful platform, and its core functionality, caching system and theming layer help ensure your site is accessible, performant, and SEO friendly. Once you’ve decoupled Drupal and you’re not using it to render your site, a lot of that functionality disappears, and you’re on your own to determine how to account for it all. You will also need to provide yourself with a way to preview rendered content.
That’s a lot to think about.
Decoupling is easier when a larger team is available: FACT
This statement is absolutely true. On a decoupled site, developers have to compensate for the loss of functionality provided by the Drupal rendering engine. Decoupled sites also typically have a more complex build process, and it’s important that you have a strong back-end team to build and support the “end points” needed by the front-end team (the front-end team uses “end points” to query for the data that will be displayed).
Once Drupal is decoupled, I can use whatever method I want to render the front end: FACT
Hopefully this helps give you an idea of the power — and complexity — of decoupling Drupal. For some organizations, building a “headless” CMS could push them to a new level of engagement and interactivity with their followers. For others, it could quickly lead them down a digital path that would be hard — and expensive — to recover from.
To determine if decoupling makes sense for your organization, please don’t hesitate to give us a call today.