EDS Approaches and the One We Chose

Content Objective

Chapter 1 introduced Edge Delivery Services (EDS), and Chapter 2 covered the project setup. Before opening the repository and building blocks, I want to explain the architecture we chose for the POC.

EDS does not force every project to use the same authoring system or content source. That flexibility is useful, but it also creates confusion: two teams may both say they are “using EDS” while building very different systems.

This chapter compares the practical options, separates page authoring from runtime integrations, and explains why we used AEM with Universal Editor (xwalk) for authored pages. It also clarifies why a secured form submission used a serverless proxy instead of browser-side credentials.

The detailed cost justification belongs later, after the core capabilities, content-storage model, and operational trade-offs have been examined.

First, Separate Three Architecture Decisions

I found it easier to reason about EDS by separating three questions:

1. Where is the page authored? This determines how editors create and maintain the primary page content.
2. Where does additional data come from? A block may need structured content or live information from an API, even when the page itself is already authored.
3. Which platform serves each route? During migration or in a mixed estate, some routes may use EDS while others remain on a traditional AEM delivery stack.

These are related choices, but they are not interchangeable. An EDS page authored in Universal Editor can still call an API. A site can also serve some routes through EDS and other routes through AEM. Neither fact changes the original authoring choice.

The Approaches, Side by Side

The table is a decision map, not six mutually exclusive product packages. In particular, C, D, and E can supplement either A or B without replacing the system that supplies the primary page HTML.

A — EDS with Document Authoring

In a document-authoring approach, editors work with documents rather than managing page content through the AEM Sites page hierarchy. DA is one authoring option in this category.

This can fit editorial sites where authors primarily manage headings, copy, images, links, tables, and repeatable content patterns. The frontend still needs block conventions and quality controls, but the authoring workflow is different from the Universal Editor/xwalk approach.

I would evaluate this option when the organization wants a document-oriented editorial workflow and does not require the AEM Sites authoring model for those pages. I would not claim that it is automatically the cheapest or fastest option without comparing licensing, migration, governance, and measured performance.

B — EDS with Universal Editor on AEM (xwalk)

This is the approach used for the POC.

Page content remains in AEM's content repository, while Universal Editor provides the editing experience. The EDS delivery flow supplies the page content to the browser, where block JavaScript and CSS enhance the delivered HTML.

For an AEM developer, the distinction is worth spelling out: keeping content in JCR does not mean the browser page is rendered by the same HTL, Sling Model, and Dispatcher flow used in a traditional AEM Sites implementation.

The xwalk setup connects AEM authoring to the EDS frontend project. Universal Editor configuration describes what authors can add and edit; the block implementation describes what happens to the delivered content in the browser.

This matched the POC because the pages were primarily authored experiences, the authoring environment was AEM-based, and the team wanted to evaluate the EDS delivery model without first redesigning the entire site as a headless data application.

C — AEM as a JSON Backend

Another option is to expose data from AEM through a JSON endpoint and consume it from an EDS block. Depending on the application, that could involve a Sling Model Exporter endpoint or another appropriately designed API.

This can make sense for data that needs to be shared with another consumer or is better represented as structured JSON than as page markup.

However, fetching JSON in the browser is not equivalent to having the main page content already present in delivered HTML. A client-side request introduces an additional dependency: the browser must request the endpoint, wait for a response, handle failures, and render the result. Caching and loading strategy may reduce the impact, but they do not remove the architectural distinction.

I would not use this as the default mechanism for every editorial block merely because the content happens to live in AEM.

D — Content Fragments with GraphQL

Content Fragments are useful when information has a structured model and is reused across pages, applications, or channels. AEM GraphQL can expose that structured content to a consumer, including an EDS frontend.

This is different from modeling every page section as a Content Fragment. A product specification, location record, or reusable structured content entity may justify a model and query. A one-off editorial Hero may not.

As with any runtime API integration, the delivery design matters. If a block fetches GraphQL data in the browser, that request affects loading, failure handling, and potentially SEO. Persisted queries, caching, and an appropriate rendering strategy can help, but should be chosen against the actual requirement.

E — External Headless CMS with EDS

An EDS frontend can also consume data from an external CMS. That can be reasonable where a separate CMS already owns a specific content domain and the site needs to present that data.

The same question applies as with AEM JSON and GraphQL: is the CMS supplying the primary page content through an appropriate content pipeline, or is the browser fetching supplementary data at runtime?

Those designs have different performance and operational implications. Calling an external API from a block does not automatically give its response the same delivery characteristics as the page HTML served through EDS.

F — Hybrid EDS and Traditional AEM

A hybrid site can keep selected routes on traditional AEM while moving other routes to EDS. A routing layer determines which delivery system handles each request.

This may be useful during a phased migration or when some routes still depend on capabilities that have not been replaced in the EDS implementation.

The trade-off is operational complexity: routing ownership, navigation consistency, authentication, analytics, SEO, caching, and release processes must work across two delivery paths. “Same domain” should not be mistaken for “one implementation.”

What We Chose for the POC

We selected Approach B: EDS with Universal Editor on AEM (xwalk) for the authored page experience.

The decision was based on the content and authoring requirements:

• The POC pages were primarily authored experiences, not a collection of structured data feeds.
• AEM was already the authoring environment being evaluated.
• Universal Editor provided the authoring path for the page and its blocks.
• The frontend could focus on enhancing delivered content instead of fetching the main page content separately for every block.

In one sentence: we kept authored page content in AEM and used the xwalk/Universal Editor model to evaluate EDS delivery and block development without turning ordinary content sections into runtime JSON integrations.

This was a POC decision, not a universal rule that every AEM customer should choose xwalk.

The Secured Form Was a Separate Decision

The form submission needed to call a secured backend API. That requirement did not change where the page itself was authored.

A browser block cannot safely contain a private API credential. Also, the EDS frontend is not running inside the traditional AEM Publish servlet execution path, so adding a /bin servlet to an AEM project is not the same as creating a backend for the EDS browser request.

For this POC, the secured request went through a serverless proxy. The browser submitted the needed data to the proxy, and the proxy handled the credential-protected backend call.

A serverless proxy is not the only possible secure backend architecture. It was the boundary selected for this particular integration. The later forms and API integration chapters cover the implementation, validation, failure handling, and security considerations.

Why We Did Not Use JSON for Every Block

The main page sections were editorial content. Using an AEM JSON endpoint for each section would have added runtime fetching and frontend rendering work without a clear modeling benefit.

That does not mean AEM JSON or GraphQL is unsuitable for EDS. It means the POC did not need those integrations for its primary authored content.

The decision should also not be described as a proven performance win without measurements. The architecture avoids some runtime dependencies, but actual performance still depends on the delivered markup, images, fonts, JavaScript, network behavior, and caching.

What This Choice Means for the Rest of the Series

The next chapters follow the Universal Editor/xwalk path used in the POC:

• Chapter 4 — EDS Project Structure and Content Flow maps the repository and follows authored content into the browser.
• Chapters 5–6 explain blocks and the block development model.
• Chapter 7 covers Universal Editor definitions, models, and filters.
• Chapters 8–9 examine the block DOM and build an authorable component.
• Later chapters examine debugging, capabilities, limitations, content storage, CSS, performance, security, and integration choices.

Many block-development concepts also apply to other EDS authoring models. The exact content structure and authoring configuration do not necessarily transfer unchanged, so those differences should be checked rather than assumed.

The detailed financial and platform-value argument belongs after the technical comparisons. A useful cost decision needs to account for authoring requirements, licenses, migration effort, integrations, governance, and ongoing operations—not just the existence of an edge delivery tier.

Developer Perspective

Before implementing a block, I want to know whether its content is already in the delivered HTML or must come from another system. That determines whether the code should enhance markup, fetch data, or handle both. It also determines where I start debugging when the block is empty.

AEM Developer Perspective

The main shift is separating where content is stored from how a page is delivered and enhanced. AEM content can remain in JCR without every EDS block becoming an HTL component or a browser-side .model.json consumer.

Architect Perspective

I would make three decisions explicit in an architecture review: the primary authoring model, the policy for runtime data integrations, and the routing boundary between EDS and any remaining AEM-served pages. Those decisions affect ownership, caching, security, failure modes, and the long-term cost of operating the site.

What I Learned from the POC Decision

The useful distinction was not simply “AEM versus EDS.” We were using AEM for authoring and EDS for delivery, while treating a secured backend call as a separate integration concern.

Once those responsibilities were separated, the rest of the project structure was easier to explain: authoring configuration controlled what editors could create, delivered HTML provided the block input, and frontend code handled enhancement.

Key Takeaways

• EDS is a delivery model, not a single mandatory authoring architecture.
• Page authoring, runtime data integration, and route-level hybrid delivery are different decisions.
• DA and Universal Editor/xwalk represent different primary authoring approaches.
• AEM JSON, Content Fragments/GraphQL, and external CMS APIs can supplement an EDS page; browser-side fetching is not the same as delivering page content as HTML.
• The POC used AEM + Universal Editor (xwalk) for authored pages.
• The secured form used a serverless proxy so credentials did not live in browser code.
• The selected approach should be evaluated against content ownership, authoring needs, performance evidence, security, and operating cost—not presented as the only valid EDS design.

Next Steps

In Chapter 4 — EDS Project Structure and Content Flow, we will open the xwalk repository and follow one page from authored content to delivered HTML, block discovery, JavaScript decoration, and final presentation.

That gives the architecture choice a concrete implementation path before we start building blocks.