AEM content in React appliccation

Hi ​@jchabot86 ,

This is a common architecture pattern and there are two solid approaches depending on how tightly you want to couple the React SPA to AEM.

The most straightforward path is using AEM’s Content Fragment REST API or GraphQL API to expose your AEM-managed content as JSON that your React SPA fetches at runtime. Your authors manage the content in AEM using Content Fragments, publish it, and your React app calls the AEM GraphQL endpoint to retrieve it and render it however it needs to. This keeps your React SPA fully standalone while still letting business users control content through AEM’s authoring interface. The personalization layer sits in your React app which can combine the AEM content response with the API data it’s already fetching to produce dynamic experiences. This is the pattern Adobe calls headless AEM and it works well when your React SPA is the primary rendering layer.

The second approach is AEM’s SPA Editor, which allows AEM to be aware of your React component structure and lets authors edit content directly in the AEM page editor with live preview. This is more powerful from an authoring experience perspective but requires your React SPA to be structured around AEM’s SPA SDK, which means retrofitting your existing standalone app to register components with the AEM component mapping. Given that your SPA is already fully functional and standalone this approach has a higher integration cost but gives you the richest authoring experience.

For your specific use case where the SPA is already built and you want to add AEM-managed personalized content to specific routes, the headless Content Fragment approach is almost certainly the right call. You get clean separation of concerns, your existing React architecture doesn’t change, and authors get a familiar AEM interface to manage the personalized content segments. The dynamic data your SPA is already fetching from your API can be merged with the AEM content response client-side to produce the final personalized experience.

One thing worth thinking through early is caching strategy AEM-published Content Fragment responses can be CDN-cached aggressively for non-personalized content, but if the personalization is truly user-specific you’ll want to make sure those requests bypass CDN cache or use appropriate Vary headers.

Hi ​@jchabot86 ,

The best approach is to use AEM as a headless content provider, where you create and manage content including personalized variations in AEM and expose it through APIs like Content Fragments. Your React SPA can then fetch this content and render it on specific pages while still handling its own business logic. For dynamic scenarios, React can combine AEM content with data fetched from other APIs, ensuring flexibility. In simple terms, AEM manages content and personalization, and React is responsible for displaying and merging it with live data.

You have two options here:

First, you can stick with Content Fragments, as others have already suggested, and craft your own models and APIs for a traditional fully headless application, where the data lives in AEM and the required portions can be edited through the Content Fragment Editor. You can more here: https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/headless/journeys/developer/overview

Second, you can leverage Universal Editor. This replaces the SPA technology, which has been deprecated, and I would strongly advise staying away from it. Universal Editor allows you to target specific sections — or even the entire app — depending on your needs, using a modern WYSIWYG editor. You can check this sample of something similar built with Next.js https://meticulous.digital/blog/f/a-true-enterprise-jamstack-cms-combining-aemaacs-and-nextjs?blogcategory=JAMstack

Hope this helps.