The monolith is the risk

• Layer 1: The Content Platform: Optimizely CMS

This is where editors, content producers and administrators work. It is the system of record for structured content. Not "pages with text" but structured, typed content objects with explicit relationships and validation rules.

A news article is more than a rich text field. It is a composition of a headline (string, max 200 characters, searchable), a subtitle (string, max 500 characters), a body (rich text, localised), an author (a reference to a Person content type), a category (enum: Research, Education, Corporate) and tags (array of strings, max 10). Each field has a data type, validation rules and indexing configuration.

A person is a reusable structured component, not a paragraph buried on an "About Us" page. Name, title, email, phone, photo, department, defined once as a _component base type and referenced from any page type that needs to display a human being. Change the person's title once, and it updates everywhere they appear across every site.

This is what Carrie Hane calls atomic content, and what the COPE principle (Create Once, Publish Everywhere) demands. The content model is the product. The CMS is the tool that enforces it.

In Optimizely CMS 13, content types are defined in TypeScript using the Content JS SDK, the same language your frontend developers already think in:

 

export const PersonBlockCT = contentType({

 

  key: 'PersonBlock',

 

  displayName: 'Person',

 

  baseType: '_component',

 

  properties: {

 

    name:       { type: 'string', required: true, indexingType: 'searchable' },

 

    title:      { type: 'string', localised: true },

 

    email:      { type: 'string' },

 

    phone:      { type: 'string' },

 

    photo:      { type: 'contentReference', allowedTypes: ['_image'] },

 

    department: { type: 'string', localised: true, indexingType: 'queryable' },

 

  },

 

});

 

Define it in code. Push it to the CMS with npx @optimizely/cms-cli config push. The content type appears in the editorial interface, gets indexed in the API layer and generates strongly typed objects for your frontend, all from a single source of truth. No XML configuration files. No admin UI clicking. Code-first, version-controlled, reviewable content modelling.

• Layer 2: The Content Graph: Optimizely Graph

Here’s where it gets interesting. Every content type defined in the CMS is automatically indexed into Optimizely Graph, a global scalable GraphQL service with edge caching via Cloudflare. This is the single API that all frontend applications consume.

Frontend developers don’t need to know anything about the CMS application, .NET, C# or the backend platform. They write GraphQL queries. They get strongly typed responses. They filter, sort, paginate, and full-text search across content types in a single query.

One query. Multiple content types. Strongly typed results. Edge-cached globally. No backend coupling.

 

query SearchContent($term: String!) {

 

  _Content(

 

    where: { _fulltext: { match: $term } }

 

    limit: 20

 

  ) {

 

    items {

 

      _metadata { displayName, types, url { default } }

 

      ... on StorePage { heading, storeLocation }

 

      ... on ProductPage { heading, productCode }

 

      ... on NewsArticle { heading, subtitle }

 

    }

 

  }

 

}

 

This is the content hub that eliminates data silos. The same structured content feeds your main website, your intranet, your campaign microsites and any future digital surface, with no duplication, no synchronisation scripts, and no middleware hacks.

Relationships between content types (a product referencing a category, an article referencing an author, a department page containing sub-pages) are all explicit, typed references that Graph indexes automatically. You can traverse the entire content graph in a single query to build rich, composite views without N+1 problems or waterfall API calls.

• Layer 3: The Frontend: Your Choice

Next.js, React, Astro, Vue, and Remix: whatever your team knows best, whatever serves your users best. Each "head" is an independent application that fetches content from Graph and renders it with its own design system. You can redesign the entire frontend without touching a single line of CMS configuration. You can deploy a new head for a mobile app without asking the CMS team for permission. You can run multiple websites, public site, intranet, news portal, all from a single CMS instance with shared content types and independent visual presentation.

The Content JS SDK makes this almost absurdly simple. It takes a URL path, automatically resolves the content type, generates the right GraphQL query, returns a fully typed object and dynamically loads the correct React component. Your developers write two things: content type definitions and rendering components. The SDK handles routing, data fetching, and component resolution.

 

const result = await client.getContentByKey(

 

  ProductPageCT,

 

  'premium-widget-x200',

 

  { locale: 'en' }

 

);

 

// Fully typed: IDE autocomplete on every field

 

console.log(result.heading);       // string

 

console.log(result.productCode);   // string

 

console.log(result.category);      // 'hardware' | 'software' | ...

 

console.log(result.relatedItems);  // ProductPage[] reference

 

Here’s what people miss about headless: editors don’t lose visual control. Optimizely's Visual Builder lets content producers compose pages by dragging sections, rows, columns and elements into a layout, with live preview rendered by the actual frontend application, not a CMS approximation. The frontend registers itself as a headless application. The CMS generates a preview token. The frontend receives it, fetches unpublished content from Graph and renders it with its own components, exactly as end users will see it.

True WYSIWYG in a fully decoupled architecture. No compromise.