Experiences with AEM Headless for Large-Scale Multilingual, Multi-Region Sites

[thedarkknight1]

Hi everyone,

I've seen a lot of tutorials and resources on using AEM Headless, particularly around creating simple, small-scale sites using content fragments (e.g., this tutorial).

However, I'm curious if anyone has worked on a real-world project where AEM Headless was used to build a global, multi-region, and multilingual site.

• What were some of the key challenges you faced during implementation?
• Were there specific advantages to using AEM Headless in such a setup?
• Any pitfalls or limitations that one should be aware of before starting a similar project?
• Do you have any learnings or best practices you'd recommend?
  
  

Looking forward to hearing about your experiences and insights!

Thanks in advance!

[ChitraMadan · Accepted solution]

Hi @thedarkknight1 

I have been using AEM as a Headless CMS for over couple of years now and is working well for our organisation.

Although, it would be difficult to cover everything here, but I can let you know some of the key bullet points.

Biggest advantage in my personal experience has been the use of modern frontend languages. We are now able to modernise our front end tech stack and use latest front-end frameworks like Next.js for the pages which involves a lot of user interaction, thus enabling us to produce sophisticated user experience.

You can go through this article as to how to implement it - https://medium.com/@madanchitra13/using-aem-as-a-headless-cms-6e659b4c500f

It has been useful to us not just from FE perspective, but also from AEM development perspective, as we have to just make sure the content is right, without worrying about how it is rendered and also has the biggest advantage of streamlining your content across different channels like web, mobile and apps, as the same content can be across all of the channels.

Initial Setup: You should spend some time initially to decide and think through how you should expose your content, how the content fragments should be organised, specially if you have to cater to different brands, regions, languages, channels and products. Once this is perfected, you just have to build upon it.

Core Principles: You should define the core principle of whether to use traditional AEM or Headless or Hybrid, for your particular use case. For example, for some of the pages, we are using traditional AEM, as those are static pages and gives content authors the flexibility of having fully configurable pages, which are updated frequently.

Performance: Make sure the performance of your Headless APIs is really good, so that there is no impact on the FE page, which is using these APIs. For this, leverage as much caching as possible.

https://medium.com/@madanchitra13/caching-strategy-for-aem-as-a-headless-cms-317e7f389875

These are some of the key points to consider. Please do not hesitate to contact me for any specific queries.

Hope this was helpful.

Thanks,

Chitra

[thedarkknight1]

Hi Chitra,

Thank you for the detailed response—it was incredibly helpful! I wanted to ask a follow-up question about your hybrid setup where some pages are using traditional AEM and others are leveraging headless content.

1. How does the setup look like?

   • Are the traditional and headless pages part of the same AEM project/repository, or are they maintained separately?
   • How do you manage routing and navigation between traditional and headless pages?

2. Rendering for Traditional Pages:

   • Are these pages still using AEM’s traditional components (like HTL templates) and authored within AEM itself?

3. Rendering for Headless Pages:

   • Is the app consuming the headless content deployed on AEM, or is it a standalone SPA (e.g., built with Next.js or React and hosted on another platform)?
   • If it’s standalone, how do you ensure seamless integration between the traditional and headless content delivery?

Looking forward to learning more about how you've achieved this hybrid setup. 

Thanks again for sharing your experience!

[ChitraMadan]

Hi @thedarkknight1 ,

Please find the answers below:

1. How does the setup look like?

   • Are the traditional and headless pages part of the same AEM project/repository, or are they maintained separately? Yes, both Headless and Traditional code is part of the same repository.
   • How do you manage routing and navigation between traditional and headless pages? Routing is managed in Akamai, as that is the first layer for any request. Akamai matches the URL pattern and redirects the request to either AEM of FE stack.

2. Rendering for Traditional Pages:

   • Are these pages still using AEM’s traditional components (like HTL templates) and authored within AEM itself? Yes, they are using AEM templates, components (HTL) and are authored in AEM itself in a traditional way.

3. Rendering for Headless Pages:

   • Is the app consuming the headless content deployed on AEM, or is it a standalone SPA (e.g., built with Next.js or React and hosted on another platform)? Front end app is consuming APIs from AEM that we are exposing from the above repository that I just mentioned.
   • If it’s standalone, how do you ensure seamless integration between the traditional and headless content delivery? Its the same AEM instance hosting Headless APIs and traditional AEM pages. For Headless, you need Content Fragments and Java Code to export and for traditional, templates and components. All these can co-exist in the same repository without any issue.

Hope I was able to clarify your queries.

Thanks,

Chitra

[thedarkknight1]

Hi Chitra,

Thank you for the detailed explanation—it’s very helpful! Just to clarify, is the FE stack for the headless pages completely detached from AEM and hosted separately on another platform/server?

I understand that the traditional pages and headless content APIs are both part of AEM, but I’d like to confirm if the FE stack is independently hosted and simply consuming the APIs, with Akamai handling the routing to the appropriate destination.

Thanks again for your time and insights!

[ChitraMadan]

Hi @thedarkknight1 ,

Yes, the FE stack is hosted separately, completely independent of AEM and is just using APIs from AEM via a microservice.

Thanks,

Chitra

[thedarkknight1]

Thanks for the confirmation.