Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

SOLVED

Headless AEM integration with React

Avatar

Level 3

I have a below requirement where in we need to implement Headless AEM integrated with React. So what should be the ideal approach. I went through the available documentation which mentions about using SPA editor and content fragment.

 

Which approach should be selected and what should be the criteria to select any approach.

1 Accepted Solution

Avatar

Correct answer by
Level 5

There are many ways to build the web; most of the ways can be implemented in AEM, which one works best is going to depend on your authors. What the authors are willing to author, how involved do they get with content, and how involved do they want to get with crafting experiences?

SPA - single page application an alternative to a multi-page website. SPA Editor - AEM native editor for SPA’s Headless - a pattern where you leverage API or GraphQL to get data from server Widget - a component of a web page with clientside experience, it has basic HTML, and javascript turns into the interactive experience when loaded.

AEM Content Service - 

AEM’s Content Services leverages traditional AEM Pages to compose headless REST API endpoints, and AEM Components define, or reference, the content to expose on these endpoints. AEM Content Services allows for the same content abstractions used for authoring web pages in AEM Sites, to define the content and schemas of these HTTP APIs. The use of AEM Pages and AEM Components empowers marketers to quickly compose and update flexible JSON APIs that can power any application.

 

You should refer below for more information - 

https://experienceleague.adobe.com/docs/experience-manager-learn/getting-started-with-aem-headless/o... 

https://aem.design/blog/2021/09/10/spa-headless-widgets-and-aem 

 

View solution in original post

0 Replies

Avatar

Correct answer by
Level 5

There are many ways to build the web; most of the ways can be implemented in AEM, which one works best is going to depend on your authors. What the authors are willing to author, how involved do they get with content, and how involved do they want to get with crafting experiences?

SPA - single page application an alternative to a multi-page website. SPA Editor - AEM native editor for SPA’s Headless - a pattern where you leverage API or GraphQL to get data from server Widget - a component of a web page with clientside experience, it has basic HTML, and javascript turns into the interactive experience when loaded.

AEM Content Service - 

AEM’s Content Services leverages traditional AEM Pages to compose headless REST API endpoints, and AEM Components define, or reference, the content to expose on these endpoints. AEM Content Services allows for the same content abstractions used for authoring web pages in AEM Sites, to define the content and schemas of these HTTP APIs. The use of AEM Pages and AEM Components empowers marketers to quickly compose and update flexible JSON APIs that can power any application.

 

You should refer below for more information - 

https://experienceleague.adobe.com/docs/experience-manager-learn/getting-started-with-aem-headless/o... 

https://aem.design/blog/2021/09/10/spa-headless-widgets-and-aem 

 

Avatar

Community Advisor

Hi @sravs ,

The Headless implementation of AEM uses Content Fragments Models and Content Fragments to focus on the creation of structured, channel-neutral, and reusable fragments of content and their cross-channel delivery. 

AEM has multiple options for defining headless endpoints and delivering its content as JSON. To explore how to use the various options and chose what’s right for you please visit: 

Hope that helps you!
Regards,

Santosh

Avatar

Employee

A really good question, but its too big to define a single box that can suit everyone. In my personal view, the major criteria's that can affect the selection are

 

1. Authoring experience

2. Author proficiency and tech awareness

3. Front end technology and platform

4. Front end technology platform hosting and the release agility

5. How omnichannel content is managed and how a single source of truth for content is managed.

6. How content heavy or data heavy is the customer experience

7. How much mixed are content and data - are they slotted in the customer experience or mixed up.
8. some more which I can't think of..

Most compelling reasons for migration to React/SPA based front end are either higher performance or the decoupling of front end application from rest of the software architecture. Decoupling enables them for faster release cadence for front end experiences along with the robust page load and performance features. New age BFF like graphQL is allowing to stitch various APIs (content and data) together and deliver the customer experience. 
From AEM perspective,
1. SPA editor is excellent if you prioritise Author WYSIWYG experience over seperately hosted and deployed SPA. Remote SPA editor will be the middle ground but the content slots needs to be premarked.

2. Headless mode is excellent if you prefer content to be delivered as an API and content editing is more form based than WYSIWYG. So traditional content editors may find it bit difficult but can be excellent once they learn the basics 
3. Content services is excellent if its omnichannel content, for example, AEM delivers a headon web experience and content services deliver a mobile app.