Rethinking Drupal Architecture: Monolith, Semi-Decoupled, or Headless?

Juan Raul Garcia Canet offers a structured breakdown of three architectural approaches for Drupal: modernized monolith, semi-decoupled, and headless. The piece’s main strength lies in reinforcing a key principle—avoid rebuilding what Drupal already handles well. The monolith is positioned as governance-friendly, semi-decoupling as a fast but constrained middle ground, and headless as powerful yet complex.

This is a solid, well-structured article that provides value by contextualising architectural decisions in Drupal. While it revisits familiar arguments, it does so with clarity and practicality, especially useful for teams navigating architectural trade-offs. 

Raul Garcia argues that blindly adopting headless architectures often leads to reimplementation of built-in features like access control, caching, and content workflows. This duplication increases complexity and maintenance costs.

A modular monolith leverages Drupal’s full stack with native caching and permissions, ideal for complex editorial needs. Semi-decoupled setups offer quick API access but limited data control. Headless architectures allow fine-tuned APIs and multi-channel delivery but risk diverging from Drupal’s strengths. A hybrid using Next.js and JSON:API is proposed for scalable, SEO-friendly builds that retain editorial governance.

Rather than defaulting to a React-based SPA, teams should assess whether decoupling solves a real architectural need. Drupal offers modern capabilities—PWA support, AJAX UIs, structured APIs—without discarding core governance features. The right architecture balances control, cohesion, and clarity.

The critique of SPA overuse is timely, but not novel. While the arguments against excessive decoupling are well-articulated, many echo long-standing community discussions. The inclusion of PWA capabilities and a Drupal + Next.js hybrid suggests practical awareness, though specifics are light—especially around real-world implementation or metrics.

This article provides a solid framework for evaluating architecture, particularly for teams new to these decisions. More experienced readers may find it a thoughtful synthesis rather than a groundbreaking insight. It succeeds more as a call for moderation than a blueprint for innovation.