Headless, partially decoupled or monolithic Drupal: how to choose

“Should we go headless?” is the most common architecture question I get — and the most commonly answered with ideology instead of trade-offs. I currently work on a Drupal 10 back office feeding a Symfony front end through an API at France Télévisions, I have shipped classic Twig monoliths for a decade, and this very site is a static front end with no CMS at all. Here is the framework I actually use.

The three (and a half) options

1. Monolithic Drupal. Drupal renders everything: Twig templates, render cache, BigPipe. One deployment, one mental model. Editors get contextual editing, layout tools and instant preview for free.

2. Fully headless. Drupal becomes a content API (JSON:API, GraphQL, or custom endpoints) and a separate application — Next, Nuxt, Astro, or in our case Symfony — owns the front end. Two codebases, two deployments, a contract between them.

3. Partially decoupled (progressively decoupled). Drupal still renders pages, but specific interactive zones are handed to JavaScript components — a booking widget, a live search, a data visualisation. You keep the editorial machinery and sprinkle interactivity where it pays.

3½. No head at all. For content that changes a few times a month, a static site generator consuming markdown or a headless CMS build-time API (what tak.tn does) beats running a CMS in production.

What full headless actually costs

The benefits are real: front-end teams ship in their own stack, the API forces clean content modelling, you can serve multiple consumers (web, apps, screens) from one source of truth. But the invoice arrives quickly:

• You rebuild what Drupal gave you for free. Preview, layout per page, menus, breadcrumbs, redirects, metatags, language switching — each becomes an API design discussion and front-end code.
• Editorial preview is the classic sinkhole. “Can I see the page before publishing?” is a one-line requirement and a multi-week implementation across two systems.
• Two pipelines, two on-call surfaces. Cache invalidation across the API boundary is where bugs go to hide.
• SEO is only fine if the front end server-renders. Client-side-rendered React consuming JSON:API is how you turn a perfectly indexable site into a rendering-queue gamble.

None of these are reasons not to do it. They are reasons not to do it by default.

The questions that actually decide it

1. Who consumes the content? One website → monolith or partial decoupling. Website + mobile app + connected TV → the API layer earns its keep. (A broadcaster is the textbook case — that is why the FTV architecture makes sense.)
2. How editorial is the product? If editors compose landing pages, reorder blocks and expect WYSIWYG preview, headless will fight you. If content is structured records (programmes, products, articles) rendered through fixed designs, an API contract is natural.
3. What team do you have? Headless requires two competent teams and someone owning the contract between them. A three-person team maintaining both sides of a decoupled stack goes slower, not faster.
4. Where does interactivity live? If it is three widgets on an otherwise editorial site, progressive decoupling gives you 90% of the benefit for 10% of the cost.

My defaults

• Editorial site, one web channel → monolithic Drupal, modern Twig, aggressive caching. Boring wins.
• Editorial site with islands of app-like behaviour → partially decoupled: keep Drupal rendering, mount components where needed.
• Multi-channel content platform with separate front-end ownership → fully headless, with server-side rendering and editorial preview budgeted from day one, not discovered in sprint 9.
• Personal sites and brochureware → static, no runtime CMS at all.

The architecture is a means. The test is always the same: will editors publish faster, and will users get pages faster? If a diagram cannot answer both with a straight face, it is fashion, not architecture.

Weighing this decision for your own platform? I do architecture audits — including an honest “stay monolithic” verdict when that is the right answer.