Headless AEM integration with React | Community
Skip to main content
sravs
Community Advisor
sravsCommunity Advisor
Community Advisor
June 23, 2022
Solved

Headless AEM integration with React

  • June 23, 2022
  • 3 replies
  • 1424 views

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.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Tushar_Gupta

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/overview.html?lang=en 

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

 

3 replies

T
Adobe Employee
Tushar_GuptaAdobe EmployeeAccepted solution
Adobe Employee
June 23, 2022

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/overview.html?lang=en 

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

 

    SantoshSai
    Community Advisor
    SantoshSaiCommunity Advisor
    Community Advisor
    June 23, 2022

    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

    Santosh Sai
      Nirmal_Jose
      Adobe Employee
      Nirmal_JoseAdobe Employee
      Adobe Employee
      June 24, 2022

      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.

        Terms & ConditionsAccessibility statement

        Loading footer...