FULLSIX,
fren
H
BETC Fullsix

Headless approach

Full decoupling of the front end from the CMS for omni-channel delivery, edge performance and total reversibility.

MUHin-house headless hub
1 / None middleware, N channels
0CMS / front coupling
Go deeperBook a demo

Headless permanently separates the CMS from the front end: editors contribute in the tool they know, developers deploy an optimised Next.js front, and both layers evolve without blocking each other. No monolith, no risk of cross-layer regression.

Layer independence

Switching the CMS does not require rewriting the front end. Changing the front end does not impact the CMS. WordPress updates, Next.js version bumps and business-logic changes all happen in parallel, each within its own perimeter.

Performance and omni-channel

Rendering is static or edge-cached: pages are served in milliseconds from Cloudflare without hitting the origin. The same middleware can power a website, a mobile app and an internal tool simultaneously.

Guaranteed reversibility

The API exposed by the middleware is stable and versioned. Replacing WordPress with another CMS tomorrow, or migrating the front end to a different framework, breaks no integration - the API contract holds.

MUH headless hub architecture

Our headless foundation is built on MUH (Unified Headless Middleware), an in-house NestJS service that sits between the CMS (WordPress Bedrock) and every consumer (Next.js front ends, mobile apps, internal tools).

Three distinct layers:

  • Editorial CMS (WordPress Bedrock) - Editors work in a familiar interface. WordPress is deployed as a stateless container on BSO Kubernetes, with S3/MinIO for media storage and Redis for object caching.
  • NestJS middleware (MUH) - Queries WordPress via REST or GraphQL, normalises data (ACF, Polylang, multilingual formats), applies cross-cutting business rules, and exposes clean, documented APIs. Cache management, Next.js revalidation, secure forms and Meilisearch integration all live here.
  • Next.js front end - Consumes only the MUH API. Hybrid rendering: SSG for stable pages, ISR for frequently updated content, SSR for personalised pages. No direct CMS calls.

What this means for your CIO

  • Versioned REST/GraphQL APIs: a stable, documented contract between the front end and the CMS, independent of WordPress updates or plugin changes.
  • Perimeter security: WordPress is never exposed directly on the public network. Only the MUH API is reachable, with OAuth2/Keycloak authentication for protected areas.
  • Cloudflare edge cache: pages are served from cache in milliseconds. On every editorial publish, only the affected URLs are purged - no global cache wipe.
  • Stateless autoscaling: WordPress and NestJS pods are stateless (media on S3, sessions on Redis). Horizontal autoscaling requires no special configuration.
  • Observability: structured logs, alerts on 5xx errors and revalidation failures, Loki/Grafana dashboards on BSO.
  • Versioned @muh/* packages: adapters, forms, fixtures and CLI are published to the private GitLab registry with a semantic changelog. Every reusable component is independently upgradeable.

Measurement and monitoring

  • Page response times (TTI, LCP) measured continuously via Cloudflare Analytics and Lighthouse CI.
  • Cloudflare cache hit rate (target: above 85% on public pages).
  • Middleware revalidation errors and 5xx responses monitored and alerted in real time.