Designing for Hybrid Delivery

Optimizely CMS 13 (PaaS) is fundamentally engineered as a hybrid content engine. In the modern digital landscape, developers are no longer forced into binary choices between headless-only platforms that sacrifice editor experience and monolithic systems that resist distribution. CMS 13 provides a unified technical foundation that enables server-side rendering while simultaneously powering external API-driven frontends. This dual capability is a cornerstone of CMS 13.

Success in a complex PaaS implementation requires a delivery-agnostic mindset. Your content model must be architected to feel natural both in a C# Razor View and in a GraphQL JSON response.

1. The Dual-Delivery Paradigm: In-Process vs. Decoupled

In a high-scale architecture, your content model serves two distinct consumers with very different data lifecycles:

1. The In-Process Delivery Head: Standard .NET 10 controllers and Razor layouts. It operates on the internal object cache, using IContentLoader to fetch data from the local DXP application instance via high-speed, in-memory serialization. This is the optimal path for SEO-heavy marketing sites.
2. The Decoupled / API Head: Native mobile apps and remote websites, such as Next.js, that consume content through Optimizely Graph (GraphQL).

The technical challenge: A property that renders perfectly as a relative link in Razor might arrive as an unresolvable ID in a decoupled application if the model is not designed for cross-channel serialization.

2. Global Scaling via the Graph Attribute System

When content is synchronized from your PaaS instance to the cloud service, every property is inspected. For enterprise sites with millions of nodes, you must govern the API surface area to prevent GraphQL schema bloat.

2.1 Strategic Use of PropertyIndexingMode

The [GraphProperty] attribute is your primary lever for tailoring the cloud delivery layer.

3. Atomic Modeling: Solving the Headless Rich-Text Hurdle

Traditional HTML properties such as XhtmlString often contain CMS-internal structures that external clients cannot interpret cleanly. Remote clients may receive raw internal strings containing GUIDs rather than usable URLs.

The Media Reference Pattern: Never model a hero image as a simple string. Use ContentReference instead. In GraphQL, this resolves to a richer JSON object containing the public CDN URL, alternative text, and focal point coordinates, enabling responsive cropping without additional backend calls.

4. Modeling Purpose over Visual Appearance

To ensure content is channel-agnostic, you must move away from design-driven property naming. Model the intent of the data rather than its physical formatting.

4.1 Correct Technical Mapping

• Monolithic Naming (Poor Governance): public virtual string BlueCallToActionButton
• Semantic Naming (Scalable Architecture): public virtual string PrimaryActionLabel

5. Preview Orchestration for Remote Delivery Heads

CMS 13 addresses the headless preview problem through its updated Application Model. Editors still need real-time feedback even when rendering is decoupled.

5.1 The Technical Preview Bridge

This handshake allows the headless frontend to receive a signed token, fetch unpublished content from Graph, and render it inside the CMS iframe, preserving the traditional Optimizely editing experience.

Conclusion

Designing for hybrid delivery in CMS 13 PaaS requires a deliberate commitment to channel-agnostic modeling and active control over the API surface area. By using the [GraphProperty] attribute system carefully, you can build leaner and more performant GraphQL schemas that scale without unnecessary clutter. By ensuring rich text and media resolve sensibly across channels, and by naming properties for meaning rather than styling, you create a model that works equally well in Razor views and remote consumers. That is the difference between building content that merely renders and building content that travels well.