decoupled.io
← All Articles
Architecture

The Two-Stack Problem: Why Decoupled Architecture Needs a New Approach

Jay Callicott··10 min read

The Two-Stack Problem: Why Decoupled Architecture Needs a New Approach

If you've ever built a headless Drupal application, you've lived the two-stack problem. Your backend team manages PHP, Composer, Drush, and Drupal's module ecosystem. Your frontend team manages Node.js, npm, React, and a modern JavaScript framework. These two worlds share an API contract but almost nothing else.

The result: complex learning demands, disjointed workflows, and two separate deployment pipelines that both need to work perfectly for your application to function.

This isn't a failure of decoupled architecture — it's an unintended consequence of pairing two sophisticated ecosystems that were never designed to work together.

The Real Cost of Two Stacks

The two-stack problem isn't just about running two languages. It's about:

Hiring and team structure. You need developers who understand Drupal's entity system, configuration management, and update hooks and developers who understand React's component model, state management, and build tooling. Finding people who are fluent in both is expensive and rare.

Local development. Running a Drupal development environment alongside a Node.js development server means Docker Compose files with MySQL, Redis, PHP-FPM, Nginx, and a Node process. New team members spend a day setting up their environment before writing a line of application code.

Deployment coordination. A content model change in Drupal might require a corresponding GraphQL query update in the frontend. These need to be deployed in the right order, tested together, and rolled back together if something breaks. Two CI/CD pipelines that must be synchronized.

Maintenance burden. Drupal core updates, security patches for contributed modules, PHP version upgrades — all orthogonal to your frontend's dependency tree. You're maintaining two distinct dependency graphs with different update cadences, different vulnerability databases, and different upgrade strategies.

What Drupal Does Well

Before proposing a solution, it's worth acknowledging why Drupal remains relevant in a landscape full of headless CMS alternatives.

Structured content modeling. Drupal's entity-field system is genuinely powerful. Content types with typed fields, entity references, paragraphs for component-based content, taxonomy vocabularies, and content moderation workflows — this is sophisticated data modeling that takes months to replicate in a green-field system.

Content governance. Revision history, editorial workflows, role-based access control, and multi-language support are built-in. For organizations that need content governance, Drupal provides it without plugins or third-party services.

Open-source data ownership. Unlike proprietary headless CMS platforms, your content lives in a database you control. You can export it, migrate it, or self-host it. There's no vendor lock-in on the data layer.

The problem isn't Drupal itself. The problem is everything that surrounds a Drupal deployment: the infrastructure, the maintenance, the PHP expertise, and the coordination cost of running it alongside a modern frontend.

Abstracting the Backend

The solution isn't to replace Drupal — it's to abstract the operational complexity so that frontend developers never need to think about PHP, Composer, or Drupal's update lifecycle.

This is the approach we've taken with Decoupled.io:

Managed infrastructure. Drupal spaces are provisioned automatically with a single API call or MCP tool. No Docker Compose, no server configuration, no SSH. The infrastructure scales automatically and handles security patches, core updates, and module maintenance.

API-first content delivery. Content is exposed through both GraphQL (via GraphQL Compose) and JSON:API (built into Drupal core). Frontend developers interact with well-documented APIs, not Drupal internals.

AI-native management. Instead of learning the Drupal admin panel, developers use MCP tools through their AI assistant to create content types, import data, manage environments, and generate integration code. The CMS management happens conversationally.

Curated module set. Rather than supporting thousands of contributed modules — each with its own update schedule and compatibility matrix — the platform provides a curated set of essential modules that are tested and maintained together. This trades Drupal's traditional extensibility for operational reliability.

The Trade-Off

This approach deliberately constrains Drupal's flexibility. You can't SSH into the server and install arbitrary PHP modules. You can't write custom Drupal hooks or override theme templates.

For the ~80% of use cases that need structured content, media management, and API delivery, this constraint is a feature. The Drupal instance becomes a predictable, maintainable content engine rather than a customizable application platform.

For the ~20% of use cases that need deep Drupal customization — custom entity types, complex access control logic, integration with legacy PHP systems — a self-hosted Drupal instance remains the right choice. But those teams already have PHP expertise on staff.

What This Means for Frontend Developers

For frontend developers using modern tools — whether that's Next.js, Remix, Vite, or AI-powered builders like Lovable and Bolt.new — the two-stack problem dissolves:

  • No PHP environment to set up or maintain
  • No Drupal knowledge required for day-to-day development
  • API-driven content that works with any frontend framework
  • AI-assisted management through MCP tools in your existing workflow
  • One deployment pipeline — your frontend is the only thing you deploy

The CMS becomes a managed service that provides structured content through APIs. The frontend remains the domain of the frontend developer, built with the tools they choose.

From Two Stacks to Two Concerns

The two-stack problem doesn't go away by ignoring one of the stacks. It goes away by making one of the stacks invisible.

Drupal's strengths in content modeling, governance, and structured data remain. But the operational overhead — the PHP runtime, the module maintenance, the infrastructure management — gets absorbed by the platform.

What's left is a clean separation: content as a service on one side, frontend as an application on the other. Connected by APIs. Managed through AI. Deployed independently.

That's not two stacks. That's two concerns — and each one can be handled by the people best equipped to handle it.

Want to try the single-stack experience? Create a free space and connect your frontend in under 10 minutes. No PHP required.