Three Ways to Integrate Dynamic Content into an EDS Site

Edge Delivery Services (EDS) is optimized for fast, mostly-static delivery - but most real sites still need dynamic content: product data, inventory, personalization, or app-like views. Today, there are three primary patterns for bringing that dynamic content into an EDS site, plus a third “advanced” option you can layer in as your architecture matures.

1. Bring Your Own Markup (BYOM)

Bring Your Own Markup lets you integrate dynamic experiences by serving fully-rendered HTML from your own backend or service, which EDS then treats as block markup.

At a high level:

• You define an EDS block that points to an external endpoint.
• That endpoint returns HTML that matches the expected block structure.
• EDS simply includes that HTML in the page, as if it were authored content.

Because the HTML is rendered upstream, you can use any language or framework (Node, Java, .NET, etc.) and still deliver an EDS-friendly experience.

Pros

• Server-rendered HTML is SEO-friendly and works with JavaScript disabled.
• Dynamic content can still benefit from caching if responses are cacheable.
• You can reuse existing backend services or apps without rewriting them as client-side code.

Cons

• You must ensure the returned HTML matches EDS block conventions and stays stable over time.
• More moving parts: deployment, monitoring, and error handling for your BYOM service.
• Personalization and experimentation need to be coordinated so they don’t conflict with what the backend renders.

2. Client-Side Fetching (With or Without API Mesh)

The second common pattern is to render dynamic content entirely in the browser:

• An EDS block loads with a minimal placeholder.
• Client-side JavaScript runs on page load
• That JavaScript calls one or more APIs (REST or GraphQL), then updates the DOM with the returned data.

You can call APIs directly from the browser, or you can put Adobe API Mesh in front of them to aggregate multiple backends into a single, front-end-friendly endpoint.

With API Mesh:

• You configure multiple upstream APIs (Adobe or third-party).
• Mesh exposes a single GraphQL endpoint to your EDS block.
• The block issues one query and gets a composed response.

Pros

• Very flexible: you can gradually add or change APIs without touching the EDS delivery pipeline.
• API Mesh can simplify the front end by hiding multiple backends behind one endpoint.
• Great fit for highly interactive widgets that update frequently after initial page load.

Cons

• Client-side fetching adds JavaScript and network calls, which can hurt performance if not carefully optimized (lazy loading, caching, batching).
• SEO can be impacted if critical content only appears after client-side rendering.
• You must handle CORS, authentication, and error states in the browser.

3. Edge-Side Integration

A third, more advanced option is to integrate dynamic content at the edge, using a worker or edge function in front of your EDS site:

• An edge worker (for example Akamai Edge, or Cloudflare Worker) intercepts the request.
• It calls your APIs, personalisation engines, or other backends.
• It injects the dynamic data into the HTML before the response reaches the browser.

This is essentially server-side rendering at the edge, but still compatible with EDS’s static-first model.

Pros

• Dynamic content is present in the initial HTML: good for SEO and performance.
• API keys and credentials stay on the Worker side, not in the browser.
• Fewer client-side scripts and network calls for the user.

Cons

• More operational complexity (deploying and monitoring edge functions).
• You must be very careful with caching and cache keys so personalization or user-specific data doesn’t leak.
• Debugging can be trickier because logic spans authoring, EDS, and edge compute.

Summary: When to Use Which

Bring Your Own Markup

Backend-heavy or legacy apps you want to surface in EDS

More backend work; strict HTML discipline

Client-Side Fetching (+Mesh)

Interactive widgets, dashboards, API aggregation

More JS in browser; SEO/performance risks

Edge-Side Integration

SEO-critical dynamic content with secure APIs

Higher ops complexity; careful caching needed

Most EDS projects end up using a mix: BYOM for “big” server-rendered chunks, client-side fetching (often via API Mesh) for widgets and app-like elements, and edge-side integration for advanced personalization or high-value dynamic content.

If you want, I can follow up with a second post that shows concrete code sketches for all three patterns (one BYOM block, one client-side block using Mesh, and one edge worker that enriches HTML).