Headless Drupal Developer | React, JSON:API & GraphQL

Decoupling the CMS from the front end buys real things: multiple channels from one content source, a front end that can be rebuilt without touching the CMS, and rendering choices a traditional theme cannot offer. It also costs real things. This page covers both, because the decision is more often made on fashion than on requirements.

When headless is genuinely the right call

Multiple consumers. A website, a mobile app, digital signage and a partner feed all drawing from one content source. This is the strongest case by a distance.
A front end with its own life. Heavy interactivity, a design system shared with a product, or a team that works in React and should not need to learn Twig.
Replatforming in stages. Decoupling lets you replace the front end and the back end on separate timelines rather than in one high-risk cutover.
Editorial and delivery separated deliberately. The CMS sits on the private network; only the rendered output is public.

When it is not

For a content site with one web front end, going headless typically means rebuilding capabilities you already had for free: preview, layout control for editors, URL management, redirects, forms, search, sitemaps and menus all become work.

The editorial experience is where this hurts most. Editors lose in-context preview and layout tools unless you invest in rebuilding them, and a content team that cannot see what they are publishing will route around the system. I have seen more headless projects struggle on that than on any technical issue — and I would rather talk you out of it up front than deliver something your content team resents.

API design

Drupal ships JSON:API in core, which covers most needs without custom endpoints and gives you filtering, includes and sparse fieldsets. GraphQL suits front ends that need to shape queries precisely and want a typed schema, at the cost of more setup and more care around caching and query complexity limits. Custom REST endpoints remain the right answer for purpose-built responses where you want to control the payload exactly.

Whichever, the same concerns apply: authentication, rate limiting, response caching with correct invalidation, and versioning so a front-end deploy and a back-end deploy do not have to happen simultaneously.

Rendering strategy

The choice that determines both performance and operational complexity. Static generation gives the best performance and resilience but needs a build-and-deploy step on content change, which is painful above a certain page count or update frequency. Server-side rendering handles frequently-changing content but puts a Node process in your critical path to maintain and scale. Incremental static regeneration sits between them and is usually the pragmatic answer.

Caching gets harder here, not easier: you now have cache layers in the CMS, at the API, in the front end and at the CDN, and invalidation has to propagate through all of them. Getting cache tags to flow from Drupal through to CDN purges is a specific piece of work worth planning for rather than discovering.

Preview, and everything else editors expect

Preview is the single most underestimated part of a headless build. Editors need to see unpublished changes rendered as they will appear, which means the front end has to fetch draft content with authentication, and a preview deployment has to exist. Budget for it properly — a headless platform without working preview will be resented from launch.

The same applies to the rest of what a traditional CMS gave you: menus, redirects, sitemap generation, forms, and search. Each becomes an explicit task.

See this in practice: Headless Drupal & React Platform

Common questions

Is headless faster than a traditional CMS?

Not automatically. A well-cached traditional Drupal or WordPress site behind a CDN can be extremely fast, and a poorly-built headless site making many uncached API calls can be slow. Headless makes certain optimisations easier, particularly static generation, but the performance argument on its own is rarely sufficient justification.

Can we keep our existing Drupal site and add a React front end?

Yes, and it is often the sensible path. Drupal can serve its traditional front end while exposing JSON:API for a new one, which lets you build and validate the decoupled front end on a section of the site before committing. It also gives you a rollback that does not involve reversing a migration.

What happens to SEO?

It works fine provided pages are rendered server-side or statically, with correct metadata, structured data, canonical URLs and a sitemap. The failure mode is a purely client-rendered front end where crawlers see an empty shell. That decision has to be made deliberately at the start rather than discovered when traffic falls.

How much more does headless cost to build?

Meaningfully more for a single-channel site, because you are rebuilding preview, menus, redirects, forms and search that the CMS provided. The gap narrows as channels are added, which is exactly why the multi-channel case is the strong one. I would rather give you a realistic comparison during discovery than have the difference emerge mid-build.

Which front-end framework do you recommend?

React with Next.js for most cases — the ecosystem is mature, rendering strategies are flexible, and hiring for it is straightforward. The more important question is usually who maintains it. A framework your team already knows beats a technically superior one nobody on staff can work in.