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.

in this scenario, the React application is a fully standalone SPA and not tightly integrated with AEM. The requirement is to use AEM Managed content and also enable personalization.

The best practice is to treat AEM as a Headless CMS, Adobe Target as the personalization decision engine and react as the rendering layer.

The approach is, Content should be created and managed in AEM using Content Fragments which expose the content via GraphQL. The React SPA integrates Adobe Target using Web SDK or at.js, at runtime it calls Target, which evaluates the user (based on audience, behavior .. etc.) and returns a variant decision. Based on the variant returned by Target, the react application calls the appropriate AEM API endpoint to fetch the corresponding content variation and render the personalized experience.

Hello ​@jchabot86 

For a standalone React SPA, the recommended approach is to keep React responsible for routing, rendering, and runtime logic, while using AEM as a headless content source for the business-managed portions of the experience.

In practice, that usually means:

• authoring reusable content in AEM Content Fragments
• delivering that content to the React app through AEM GraphQL APIs
• letting the React app combine AEM-managed content with any live API data it already fetches

For personalization, there are two common patterns:

1. App-driven personalization – if the React app already knows the user or business context from its APIs, the app can request and render the appropriate AEM content variation.
2. Target-driven personalization – if the business wants audience targeting, experimentation, or A/B testing at scale, the preferred pattern is to use Adobe Target with AEM-authored content, and let React render the selected experience.

If authors need in-context visual editing inside the external React application, the recommended modern path is Universal Editor rather than trying to move the SPA into legacy AEM SPA patterns.

-->In short:<--
AEM manages the content, React assembles the experience, APIs provide live business data, and Target handles advanced personalization when needed.

This gives the business authoring control without forcing the standalone SPA to be replatformed into AEM.

 1) Best to use Headless Fashion - Content Fragment,GraphQL with Next JS(Next Js is recommended- Here NEXT JS support - SSR,ISR,SSG - so decided these rendering process for Personalization on page ). 2)  Here For personalization means - user specific data ? common data - If it is specific to user - then login required or Adobe Target with offers.

Hi ​@jchabot86 

There are a few possible approaches for integrating AEM-managed content and personalization into a standalone React SPA, and I think the right choice largely depends on where we want content ownership, layout orchestration, and personalization decisions to reside.

Option 1: Headless Content Delivery (AEM Content Fragments + GraphQL)

If the React application is intended to remain the primary owner of routing, page composition, and rendering, a headless approach may be the cleanest option.

In this model:
- AEM acts as a content repository through Content Fragments and GraphQL APIs.
- The React application fetches content based on route or component context.
- Personalization can be handled through Adobe Target/AEP Web SDK or any existing personalization layer already present in the application.

This approach keeps React fully decoupled from AEM page structure while still allowing authors to manage content centrally.

For dynamic API-driven data, React components can naturally combine data from backend services with content retrieved from AEM before rendering.

Option 2: AEM SPA Editor / Remote Page Editing

If the requirement is for business users or marketers to assemble page layouts and experiences directly within AEM, then SPA Editor may be worth evaluating.

In this model:
- React components are mapped to AEM resource types.
- AEM provides page structure as JSON.
- The React application renders components dynamically based on the authored layout.
- Personalization can be applied at the AEM/Adobe Target layer before the layout reaches the SPA.

The main benefit is authoring flexibility; however, it introduces tighter coupling between the React application and AEM's page model and generally increases implementation complexity.

Option 3: Experience Fragment-Based Integration

If the requirement is limited to personalizing specific sections of the SPA (e.g., banners, promotional content, CTAs, footers, recommendation areas), Experience Fragments may provide a lighter-weight solution.

In this model:
- The React application owns the overall page.
- Specific content slots are reserved for AEM-managed experiences.
- Adobe Target or Experience Edge delivers the appropriate fragment variation based on audience rules.

This allows us to introduce AEM-driven personalization without requiring the entire page composition model to move into AEM.

For components that also require dynamic application data, React can populate placeholders or data attributes after the fragment is rendered.

My inclination would be:

- Headless GraphQL if React should remain the source of truth for page composition and application behavior.
- Experience Fragments if the goal is targeted personalization within selected regions of the page.
- SPA Editor only if there is a strong business requirement for marketers to assemble and manage complete page layouts directly within AEM.