Hybrid AEM Architecture for Modern Web Frameworks

Audience : AEM Architects, Leads and Developers

This blog highlights and addresses commonly faced issues while building scalable, dynamic enterprise applications using popular front-end frameworks with AEM (Adobe Experience Manager). Even though there are some tools available to address issues faced with Single Page Applications (SPA), when it comes to traditional (Non-SPA) applications, there is dearth of documentation on most of the issues faced while working with React and Angular.

Introduction

1. Content-driven: Requires frequent content updates, hence business/ marketing team needs to have full control on the application.

2. Dynamic: Most of the pages have some sort of dynamic functionality which either takes input from user and makes API calls to fetch some data from third or first party.

3. SEO: Most of the pages have SEO value and drives traffic directly from search engines through deep linking.

4. Authentication: Some pages of the application require the user to be authenticated.

Current Approaches

1. With headless approach, SEO is difficult to achieve as the rendering happens on client-side using SPA’s.

2. With headful approach, it is difficult to achieve dynamic functionalities.

3. If implemented in mixed mode (Headless + headful) applications suffer with performance, maintenance issues.

Since there is a good mixture of static and dynamic behavior on the application, the existing approaches fall short of providing a scalable, maintainable, discoverable platform on which the application can be developed.

Proposed Approach

Need for MPA against SPA

1. Retain SEO Value of the web property

2. Simplicity of development

3. Cache-ability

4. SSR in AEM + SPA is complicated and not recommended by AEM vendors.

5. Only a portion of the page needs to be rendered using front-end library as against to a whole page.

In the following sections, key tenets of this approach are discussed in detail.

Design considerations

Component Boundary Definition

1. Nesting: multiple levels of nesting should be avoided as it would be difficult to implement in front-end. Nesting is seemingly taken care effortlessly in native AEM component, but this would be challenging in its front-end counterpart as it would mean extra effort to implement propagation of dialog variables from parent to child components.

2. Granularity v/s Reusability: More granular the components are designed; more reusable they will be. But more granularity would result in nesting which should be avoided. Hence one would end up in a situation where the reusability of the components suffers.

3. Dynamic Variations: While defining a component, all dynamic variations should be considered. For example: pop-up modals that component produces on interaction. When the content of the component changes based on user-interaction or API response, all possible variation of that component needs to be taken into consideration while defining the component boundary.

Consider a simple login form. This form can be broken down in many ways. Hypothetically, let’s assume we are breaking it down to most granular form for better re-usability. If this was an AEM Native component, this would be practical. But, considering authoring dialogs and complexities of reading those values in front-end component, we would be better off considering this as a monolith (a single login component). This only makes sense because the front-end logic written to make this component work would work only if all elements are present.

Project structure for clear segregation

Approach decision — Native v/s Front-end

A note on headless content

AEM and Front-end Handshake

Implementation Considerations

Propagating content from AEM to front-end

Sightly HTML

Frontend (React example)

Build Process

Debugging

Source Map generation

Handling Performance issues

Improving page load speeds by optimizing CSS and JS inclusions

*Scores calculated with conditions: AEM Publish 6.5.7, Dispatcher 4.1.5, Front-end prod build, Apache HTTPD 2.2, with pre-caching, HTTP 1.1 and Windows 10

Loading web assets

Different load times on native and front-end components

Logistical Considerations

Team and work break-down

Conclusion

Software Architect