Enterprise Pharma Web Platform

The problem it solves

AEM EDS provides component data as deeply nested HTML - the output of the Universal Editor dialog. Without a framework, every developer writes their own querySelector logic to extract each field. On a five-person team, this produces five different patterns for the same problem.

How it works

Each AEM component has a JSON model defined in its dialog configuration - the canonical field map authored in Universal Editor. The framework reads this model at build time and uses it to drive automatic extraction at runtime. The developer calls a single function, passing the block element. The framework traverses the nested HTML, maps each node to its corresponding dialog field by position and type, and returns a plain object whose keys exactly match the component model.

// Without framework - each developer writes their own extraction
const title = block.querySelector(':scope > div:nth-child(1) > div').textContent
const image = block.querySelector(':scope > div:nth-child(2) > div > picture')
const cta   = block.querySelector(':scope > div:nth-child(3) > div > a')

// With framework - one call, keys match the dialog model exactly
const component = generateComponentObj(block)

// component is now a typed object:
// {
//   title:       "Hero headline text",
//   image:       <picture>,
//   cta:         { text: "Learn more", href: "/page" },
//   description: "Supporting copy...",
//   ...
// }

// Rendering uses the object directly - no selector knowledge required
block.innerHTML = `
  <h2>${component.title}</h2>
  <p>${component.description}</p>
  <a href="${component.cta.href}">${component.cta.text}</a>
`

Because the returned keys are derived from the component model, not hardcoded selectors, the object is self-documenting and stable across refactors. Adding a new dialog field extends the object automatically - no extraction code to update. Developers write only rendering logic and component-specific behavior.

Impact

• —Reduced component development effort by 40% and eliminated an entire category of bugs caused by inconsistent dialog field extraction.
• —Model-driven architecture means component updates driven by evolving business requirements require little to no data-extraction refactoring.

The gap

EDS has no native mechanism for injecting user-specific content at request time. Handling this client-side would expose API credentials and introduce a visible loading phase - both unacceptable for a pharma corporate site.

Proposed approach

A Cloudflare Worker acting as a lightweight SSR layer at the edge. On each request, the Worker intercepts the EDS HTML response, fetches the relevant user data from a database or external API, injects it directly into the markup, and forwards the complete response to the browser.

// Cloudflare Worker - edge personalization pattern
export default {
  async fetch(request, env) {
    const response = await fetch(request)           // fetch EDS page
    const html     = await response.text()

    const userId   = getUserIdFromCookie(request)
    const userData = await env.DB.get(userId)       // D1 / external API

    const personalized = injectUserData(html, userData)

    return new Response(personalized, response)
  }
}

Why it matters

• —No API calls exposed to the client - credentials stay server-side.
• —No additional application server - the Worker is the personalization layer.
• —Consistent with the existing Cloudflare-first architecture already in place.