the-composable-frontend-architecture

Data-Driven Presentation Layer (DPL)

By Everett Quebral
Picture of the author
Published on

Introduction

In a composable architecture, presentation is not hardcoded—it is driven by data. As applications become more modular and adaptive, the traditional separation between data and UI begins to blur. Frontend components no longer simply render what they’re given—they decide how and when to render based on structured content, user attributes, and dynamic configuration.

Importantly, in a data-driven model, “data” encompasses more than just structured content. It includes user context, session metadata, feature flags, personalization signals, and even decision engine outputs. This data drives not only what gets rendered—but how, when, and to whom.

This chapter explores the role of data-driven presentation as a core strategy in composable frontend systems. We’ll examine how structured data enables UI flexibility, empowers non-developers, and forms the foundation of adaptive design.

We’ll cover:

  • Structured content and schema-driven UI composition
  • UI as configuration: from CMS to JSON-based layout systems
  • Real-time rendering from content graphs and APIs
  • Headless data pipelines and UI orchestration
  • Governance, validation, and preview workflows for dynamic content

“In data-driven systems, content isn’t inserted into the UI—the UI is rendered from the content.”

By the end of this chapter, you’ll understand how to model, structure, and govern data to power flexible, scalable, and resilient frontend interfaces.

Structured Content and Schema-Driven UI Composition

At the heart of data-driven presentation is structured content: data that follows a schema and separates structure from styling. Structured content enables UIs to render dynamically, allowing non-developers to influence layout and display through content alone.

What It Means to Be Schema-Driven

  • Every block of UI (e.g., HeroBanner, CTA, CardGrid) is mapped to a schema.
  • The frontend parses this schema to render layout, spacing, and hierarchy.
  • This creates a model where content and configuration become inputs to UI composition.

Real-World Example: The Atlassian Design Ecosystem

Atlassian’s design platform enables marketers and product managers to create landing pages using schema-driven templates. These templates expose content fields through Contentful, which are then parsed by a unified rendering engine. According to a frontend architect at Atlassian:

“The schema became our API. It forced alignment between design, product, and engineering.”

The result? Teams ship new pages in hours, not sprints—and updates to structure can be made without developer intervention.

UI as Configuration: JSON-Driven Layout Systems

Data-driven UIs often use JSON or declarative objects to define what the UI should look like. Instead of hardcoded pages, teams now author layouts as structured configuration files.

[
  { "type": "HeroBanner", "props": { "title": "Welcome" } },
  { "type": "ProductGrid", "props": { "items": [1,2,3] } }
]

Real-World Example: Shopify Hydrogen & JSON Layouts

In Hydrogen, Shopify's React-based storefront framework, page content is sourced as JSON from Shopify’s Storefront API. Each content block maps to a component. According to a developer lead:

“Our merchandisers can now build a Black Friday campaign from structured JSON, preview it in staging, and ship it—without pinging a single dev.”

This shift drastically reduced engineering bottlenecks and enabled more creative freedom on the business side.

Real-Time Rendering from Content Graphs and APIs

Structured content often lives in a content graph—where references, localization, and personalization attributes create dynamic relationships between content entities. Rendering happens by querying this graph in real time.

The Content Graph as a Platform Layer

Modern platforms treat structured content as a graph—not just for querying, but for execution. Entities like “Hero”, “ProductCard”, or “FAQBlock” form nodes that can be composed, versioned, and reused across contexts.

Organizations like Spotify and IKEA have internal content graph gateways that unify CMS, PIM, and personalization data into a runtime decision layer. This enables teams to build with intelligent composition, not just templating.

Real-World Example: Netflix Studio CMS

Netflix uses a custom CMS to power title landing pages for global audiences. The CMS stores content as nested components in a graph. Pages render by resolving that graph in real time, merging in regional preferences, A/B flags, and device form factors.

“We no longer build pages. We model them.” — Netflix Studio Engineer

This model allows Netflix to localize UI structure for over 190 markets without branching the frontend codebase.

Headless Data Pipelines and UI Orchestration

Behind the scenes, content from various sources is orchestrated, transformed, and streamed to the frontend. This orchestration is often done at the edge, enabling serverless personalization and layout configuration.

In mature systems, orchestration includes:

  • Edge execution of layout metadata and personalization payloads
  • Schema stitching via tools like GraphQL Mesh
  • Backend-for-Frontend (BFF) layers aggregating content and behavioral data
  • Decision engines for feature targeting, personalization, and content shaping

This results in a clean separation between UI logic and runtime assembly of the page, making frontend layers lighter and more adaptable.

Tools like Uniform.dev, Apollo Federation, and GraphQL Mesh enable composable content orchestration across diverse systems.

Real-World Example: Vercel Edge Middleware at HashiCorp

HashiCorp uses Vercel’s edge middleware to inject layout configuration and feature flags into requests. Pages are rendered based on both the static content from Sanity and runtime metadata injected into the HTML shell.

“We have a unified page shell. What goes inside is entirely determined by edge-executed layout composition.”

This approach dramatically reduced page weight and enabled precise control over what users see—before JavaScript even loads.

Governance, Validation, and Preview Workflows

As dynamic rendering becomes more widespread, guardrails must be in place. Without governance, flexibility can lead to fragmentation, bugs, or accessibility issues.

Governance is achieved through:

  • Schema versioning and contracts: using tools like json-schema and zod to enforce structure
  • CI/CD validation workflows: incorporating @contentful/rich-text-types, json-schema-to-typescript, and ajv for schema linting
  • Prop validation and runtime guards: ensuring layouts don’t break due to malformed configuration
  • Visual regression and design integrity enforcement: with Storybook’s accessibility add-ons, Chromatic, and design token validators
  • Preview tooling for live feedback: using platforms like TinaCMS, Builder.io, or Stackbit to enable inline editing, live preview, and multi-role testing workflows

Reference: Storybook Controls and Adobe’s Spectrum Design System

Real-World Example: Adobe Experience Manager + React Spectrum

Adobe combines AEM’s structured authoring tools with its internal React Spectrum design system. Component contracts are strictly enforced with schema validation, token linting, and Storybook-based previews.

“The content team never sees raw code. They see live previews with warnings if something breaks the system.”

This architecture empowers content creators without compromising accessibility or design consistency.

“Data is no longer content’s passenger. It’s the driver.”

Summary and Next Steps

Data-driven presentation is the natural evolution of component-based UIs. It shifts control from code to content, enabling teams to scale experience design without scaling engineering overhead. And it expands the definition of data—not just as structured content, but as contextual signals, user behavior, and orchestration inputs.

Data-driven presentation is not a side concept—it is the foundation of scalable, personalized, and composable user interfaces. It allows platforms to:

  • Scale UI content without growing engineering effort
  • Enable marketers, designers, and product teams to build UI experiences directly
  • Separate rendering from code, making UIs more adaptive, testable, and reusable

Ignoring data-driven presentation means limiting what’s possible with composability. Every high-performing digital platform today—Netflix, Shopify, Atlassian, Adobe—is already embracing it.

“Data is no longer content’s passenger. It’s the driver.”

Key Takeaways:

  • Structured content and schemas decouple UI from implementation.
  • JSON-based layouts and orchestration pipelines enable dynamic rendering.
  • Governance ensures flexibility doesn’t compromise quality.
  • Organizations that embrace this model unlock faster iteration, clearer roles, and higher-quality UIs.

Stay Tuned

Want to become a Next.js pro?
The best articles, links and news related to web development delivered once a week to your inbox.