Progressively decoupled Drupal has gone from concept to buzzword. Until recently, when we've started to witness sustained efforts being made to set up a standard workflow for implementing this architecture.
New dedicated modules have been developed to fit those use cases where just a few particular blocks, affecting the website's overall performance, need to be decoupled. All while preserving Drupal's standard robust features.
Features too famous among content editors and site builders to be sacrificed in the name of high speed and rich UX.
We've gradually shifted focus from “Why would I choose progressive decoupling over a headless CMS?” to:
“How precisely do I implement the progressive approach into my own decoupled Drupal project? Is there a standardized process, based on a set of dedicated modules, that I can leverage?”
And this is what I'll be focusing on in this post here.
More precisely, on the efforts for standardizing the whole workflow: see Decoupled Blocks and the SPALP module!
1. Progressively Decoupled Drupal: Compromise or Viable Alternative to an All-In Transition?
Is this approach nothing but a compromise between:
- content editors — and all Drupal users working in the site assembly — who depend on key features like content workflow, layout management, site preview, seamless administrative experience
- and front-end developers, who're “dying” to “inject” application-like interactivity and high-speed front-end technologies into certain portions of the Drupal web pages?
Progressively decoupling blocks in Drupal is, indeed, the best compromise you could get between:
- your editorial team's “fear” of losing familiar Drupal features critical for their workflow
- front-end developers willing to experiment with new technologies promising top speed and richer user experiences
But does being a viable compromise makes it also a worthy alternative to the fully decoupling option?
- it caters to all those who haven't been won over by the “headless CM movement”
- it removes the risk of trading vital Drupal functionality for the benefits of a powerful front-end framework
In other words:
For all those Drupal projects requiring that only certain components should be decoupled, an all-in transition would be simply... redundant and unnecessarily risky.
For all those projects there's the progressively decoupled Drupal alternative.
2. Why Has this Approach to Decoupling Drupal Been So Unpopular?
How come the progressively decoupled Drupal strategy gained so little traction?
It seems that despite its drawbacks — the need to reinvent some of the lost “Drupal wheels” and its higher costs — the fully decoupled approach has been more popular.
And there are 3 main causes for this, that Dries Buytaert identified and exposed in his blog post on “How to Decouple Drupal in 2018”:
- progressive decoupling doesn't leverage server-side rendering via Node.js
3. The SPALP Module: Towards a Standard Workflow for Implementing Progressive Decoupling
Now, back to this blog post's main topic:
Clear pieces of evidence that we're finally heading towards a standardized process for implementing this type of decoupled system.
Here's a specific use case, so you can get an idea of its role in the entire workflow of a progressively decoupled Drupal project:
- you stay consistent and “joggle with” the same configuration every time you need to add a new app to your Drupal website
“And how does this module work?”
Here's the whole “back-stage” mechanism:
- the SPALP module helps you to set up a new “app landing page" content type, the one providing the URL for the app about to be integrated
- each one of these applications must have its own module that would declare a dependency on SPALP, include its JSON configuration and define its library
- once a module meeting all these requirements is enabled, SPALP will create a landing page node for it, which will store the initial configuration
- the SPALP module will add the pre-defined library and a link to an endpoint serving JSON each time that node is viewed
Note: speaking of the efforts made to create a “Drupal way” of implementing this decoupled architecture, you might want to check out Decoupled Blocks, as well. It's designed to empower front-end developers to use the JS framework of their choice to develop individual custom blocks that would be later on integrated into Drupal. No Drupal API knowledge required!
What do you think: will the community continue their efforts to build a standard workflow for the progressively decoupled Drupal approach? Or will it remain a conceptual alternative to headless Drupal?