Progressively Decoupled Drupal: Moving Towards a Standard Workflow

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:
 

1. your editorial team's “fear” of losing familiar Drupal features critical for their workflow
2. front-end developers willing to experiment with new technologies promising top speed and richer user experiences
    

Developers get to leverage the JavaScript framework of their choice without interfering with the site assemblers' workflow. Flexibility at its best!

But does being a viable compromise makes it also a worthy alternative to the fully decoupling option?

It does.

Specifically because:
 

1. it caters to all those who haven't been won over by the “headless CM movement” 
2. 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.

As you explore progressively decoupled architectures, it's essential to understand how they can enhance omnichannel strategies, much like the benefits outlined in Leveraging Headless Drupal for Omnichannel Experiences.
 

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”:
 

1. progressive decoupling doesn't leverage server-side rendering via Node.js
2. modern JavaScript cohabits with old-school PHP
3. JavaScript's ascension is not going to stop any time soon; therefore, the risk of sacrificing some of Drupal's popular capabilities might still seem insignificant compared to the JS advantages at a front-end level
    

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.  

And one such evidence is the SPALP module: Single Page Application Landing Page. 

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:

Let's say that you need to integrate a couple of JavaScript-based one-page apps into your Drupal website. The CMS will continue to be “in charge” of the page rendering, access control routing and navigation, while the JS apps would be developed independently, outside of Drupal. How would you configure these JS apps as Drupal web pages?

You'd use the SPALP module to configure each one of them so that:
 

1. you stay consistent and “joggle with” the same configuration every time you need to add a new app to your Drupal website
2. you make its easy for your content team to manage this entire ecosystem of single-page JavaScript apps
    

“And how does this module work?”

Here's the whole “back-stage” mechanism:
 

1. 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
2. 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
3. once a module meeting all these requirements is enabled, SPALP will create a landing page node for it, which will store the initial configuration
4. 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!

The END!

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?