Skip to main content

Outline

At a glance
  • Architectural shift: Moves delivery from the CMS web server to a globally managed high-performance hub.
  • Efficiency: Replaces REST over-fetching with single-request GraphQL assembly for complex page data.
  • Decoupling: Shifts routing and URL resolution responsibilities to the frontend or edge layer.
  • Optimization: Leverages edge caching and specific content modeling to minimize latency and server load.

The adoption of Optimizely Graph in CMS 13 necessitates a significant re-evaluation of technical architecture. Moving beyond simple search indexing, "Graph-backed delivery" redefines the boundaries between the Content Management System and the presentation layer. By shifting the delivery responsibility to a globally managed high-performance hub, developers must account for changes in scaling, routing, and data interaction patterns.

1. Scaling and Resource Decoupling

In a traditional "In-Process" architecture, the CMS application handles all visitor traffic. Every request for content consumes CPU and memory on the CMS web server, often requiring additional instances to handle high traffic.

Architectural Shift:

  • Offloaded Traffic: With Graph-backed delivery, the primary traffic load is shifted from the CMS web servers to the Optimizely Graph managed service. The CMS functions primarily as an authoring hub that "pushes" updates.
  • Resilience: Because the presentation layer communicates with the Graph service rather than the CMS database, the public-facing site remains operational even during CMS maintenance or background indexing tasks.
  • Infrastructure Efficiency: This decoupling allows for smaller CMS server footprints, as the heavy lifting of data retrieval and query processing is handled by the Graph’s distributed infrastructure.

2. From REST to GraphQL: Data Fetching Efficiency

Architecture traditionally relied on REST-based APIs (like the Content Delivery API) which often resulted in "over-fetching" (retrieving more data than needed) or "under-fetching" (requiring multiple calls to assemble a page).

Architectural Shift:

  • Single-Request Assembly: GraphQL allows a single query to fetch a page, its nested blocks, and related media metadata. This eliminates the "N+1 query problem" common in REST architectures.
  • Schema Flexibility: Developers can define specific shapes for data via the GraphQL query, ensuring that mobile apps receive lightweight payloads while desktop experiences receive enriched metadata.
# Example: Fetching a landing page with nested hero and feature blocks query GetLandingPage($url: String!) { Content(where: { Route: { eq: $url } }) { items { Title Hero { Headline Image { Url } } FeatureCollection { items { id Title Description } } } } }

3. Routing Responsibility: Slugs vs. IDs

In traditional MVC patterns, the CMS manages URL resolution automatically via internal routing tables. In a Graph-backed architecture, the presentation layer (often a decoupled React or Next.js app) assumes greater responsibility for routing.

Architectural Shift:

  • Slug-based Lookups: The frontend app must resolve incoming URLs (slugs) into Content IDs via a Graph query.
  • Canonical URL Management: Developers must ensure that the "Route" or "Url" property indexed in the Graph matches the routing logic implemented in the frontend framework.
  • Edge Routing: Many modern architectures leverage Edge Middleware (e.g., Vercel Middleware or Cloudflare Workers) to handle redirects and localized routing before the request even reaches the main application logic.

4. Advanced Caching Strategies

Caching shifts from simple server-side object caching to a more sophisticated "Edge Caching" model. Optimizely Graph provides specific mechanisms to ensure high hit ratios while maintaining data freshness.

Key Caching Mechanisms:

  • Cached Templates: To reduce latency, developers can use "Cached Templates," which speed up query execution by storing translated query structures. This is highly effective when query parameters change frequently but the structure remains the same.
  • Item Queries for Specific Entities: Querying by a unique ID using item (singular) rather than items (list) significantly improves the cache hit ratio. When a single item is updated, only its specific cache entry is invalidated, preventing large-scale cache purges.

5. Content Modeling for Multi-Channel Delivery

Architecture decisions must now account for how content is "exposed" rather than just how it is "stored."

Architectural Shift:

  • Output Optimization: Properties should be modeled based on their role in the Graph. Developers use the [GraphProperty] attribute to define PropertyIndexingMode.OutputOnly for large blobs that do not require filtering.
  • Data Enrichment via Conventions: The Conventions API allows developers to "hook" into the indexing pipeline to add calculated properties or external metadata before the content lands in the Graph.
[ModuleDependency(typeof(ContentGraphIntegrationModule))] public class GraphConventionsModule : IConfigurableModule { public void ConfigureContainer(ServiceConfigurationContext context) { } public void Initialize(InitializationEngine context) { var conventions = context.Locate.Advanced.GetInstance<IContentGraphConventions>(); // Example: Add a custom calculated field 'ReadTime' during indexing conventions.ForInstancesOf<BlogPage>() .IncludeField("ReadTime", x => CalculateReadTime(x.MainBody)); } private int CalculateReadTime(XhtmlString body) => // Logic to calculate time }

Conclusion

Transitioning to Graph-backed delivery requires a pivot from traditional server-side rendering patterns to a service-oriented architectural mindset. By decoupling the delivery layer, implementers gain significant advantages in scalability and frontend flexibility. While this shift places a greater technical burden on the developer to manage routing resolution, cache-aware querying, and schema optimization, successful architectures leverage GraphQL to build performant, resilient, and multi-channel systems.