AEM Champion Office Hours: AEM Headless (September 2023)

In this AEM Champion Office Hours session on AEM headless, host Greg Dimeris and a panel of AEM Champions, including RENY director Rami El Gamal, Brett Birschbach, Max Barrass and Vengadesh Shanmugavelu, discussed when headless delivery makes sense and how to structure content for it.

What the session covers

• Headless or head-full: how to decide, and what to watch for with client-side rendering.
• Commerce architectures: combining AEM content with product data from a PIM or commerce engine in a React front end.
• Integrations: using headless AEM with Adobe Target and other Adobe tools.
• Content Fragment design: information architecture, query performance and variations for different channels.
• Multilingual sites: language masters, live copies and translations.

Key takeaways

• Headless suits stories, not campaigns. Pages that marketers constantly rearrange, change for A/B tests or build by drag and drop are usually better as head-full pages. Templated, logic-heavy experiences such as checkout flows, multi-step forms and calculators suit headless.
• Mind rendering, performance and SEO. Client-side rendering affects both. An account page may not need SEO, but it still needs to be fast.
• Is it an application or a website? If users do something and navigation is driven by state rather than URLs, a single page application may fit. If they mostly read content, a website is the better model.
• Start with what AEM provides. In a commerce front end, decide which data comes from AEM (marketing content, assets) and which comes from the PIM or commerce engine, then design APIs and information architecture to match.
• AEM is not a PIM. A few hundred products in Content Fragments is fine, but tens of thousands is not. Use the right tool for the job.
• Structure content for how you query it. Good information architecture, path-based lookups and proper indexes keep GraphQL fast. Use Content Fragment variations for channel-specific versions of the same content.
• Target is independent of AEM. It works with any front end. AEM makes creating offers easier, for example by exporting Experience Fragments to Target.

RENY's perspective

Our rules of thumb for when to use headless are above, and the typical headless stack, Content Fragments and GraphQL feeding a React app, brings rendering, performance and SEO trade-offs to plan for. For React and commerce front ends, our first question is always "why AEM headless?": define what data you need from AEM before designing the integration. There is no single best practice for Content Fragment architecture, only the needs of your business, and fragments should be easy to author and easy to extract. And keep Target decoupled from AEM: AEM simply makes it easier to create the offers.

What's changed since 2023

• The Universal Editor now gives authors visual, in-context editing of headless and hybrid experiences, reducing the authoring trade-off of going headless.
• Edge Delivery Services offers fast, server-rendered pages with document or visual authoring, which changes the headless versus head-full decision for many marketing sites.
• OpenAPI-based Content Fragment APIs now sit alongside GraphQL for delivery and management.

How RENY helps

We design headless and hybrid AEM architectures, from Content Fragment models and APIs to commerce and personalization integrations. Talk to an AEM architect.