Decoupled Drupal was a hot topic a few years ago and was often sold as a universal remedy. In many cases, it turned out to be the wrong medicine — but decoupling wouldn’t exist at all if it had no valid use-cases. So let’s dissect the promises: what’s real value, what’s wishful thinking, and when a monolith is actually the better architecture.
Over the last year I worked on two decoupled projects: one was refactoring an existing decoupled setup *back* into a monolith; the other was building a decoupled portal from scratch. In both cases, I’d argue the initial architectural choice was wrong (in different ways) — which makes them great material to discuss what goes wrong and why.
Drupal has a long-lasting reputation for being “ugly.” This largely comes from an assumption within the community that it is the developer’s responsibility to make it beautiful. There is a certain contradiction here: while Drupal’s theming layer is extremely powerful, it still carries this reputation. The missing piece is complexity — that complexity was often underestimated.
At some point, frontend development evolved rapidly: SPAs became the trend, everything turned reactive, and Drupal was still relying heavily on jQuery. Decoupling appeared to be a natural solution — a way to make Drupal “beautiful” and to attract frontend developers who had little or no interest in learning the Drupal theming layer.
Did it pay off?
First, we’ll look at architectural tradeoffs that follow from the decision to go decoupled. Drupal provides much more than HTML output: most notably, its caching model and mature authentication/authorization system. In a decoupled setup, these benefits don’t automatically transfer — they need to be re-designed and re-implemented across multiple layers. The editorial experience also becomes a challenge: Drupal’s core niche is content management and editing, and reproducing predictable previews and WYSIWYG-like behavior in a separate frontend is rarely “free.” SEO and routing must be handled deliberately as well (canonical URLs, redirects, multilingual paths, metadata, etc.).
On the other hand, building highly interactive, app-like experiences can be more difficult with traditional (monolithic) Drupal — especially if you need dynamic behavior similar to modern web apps, content delivered to multiple platforms, or the ability to deploy frontend changes independently from the CMS.
From a delivery standpoint, decoupling can bring a practical advantage: it makes the frontend team independent. They don’t need to know Drupal; they can work in familiar stacks and patterns. That opens the door to a large pool of React (or Vue/Angular) developers and can accelerate UI development. But synchronization becomes the new headache: backend and frontend effectively become separate products, and keeping the content model, API contracts, caching strategy, and release process aligned becomes part of the job.
Second, we’ll compare common backend and frontend approaches and “baked solutions”: REST vs JSON:API vs GraphQL (including GraphQL Compose), and frontend implementations in Next.js or React/Vite. Finally, we’ll look at what Canvas promises in terms of partially decoupled frontend — modernizing the presentation layer without fully giving up Drupal’s strengths in caching, routing, and editorial workflow.
