AEM + Angular app

[AshishSPanwar-a]

Hi All,

We are considering following setup for one of our projects and I would like to poll the community on their learnings having implemented such a setup in their projects.

Our front end layer would be served by an independent application (say using Angular/ReactJS hosted on Tomcat). AEM would be used purely as a content authoring and storage medium. The Angular app (desktop and mobile) would “load/fetch” content from AEM servers (including Dispatcher in front to enable content caching).

This setup is different from what usually is seen in typical AEM deployments where the content, code and presentation layer all reside in AEM. The suggested approach is finalised for implementation and I’m aware there are projects there in the wild that use this approach. It would be great if the community could share their learnings from having implemented something similar. 

- What was good or bad about this design choice? 

- Are there any specific pitfalls with this approach? 

- AEM would be used as a content storage and serving layer, any learnings that should be kept in mind (Authoring/end user experience)?

One challenge that immediately comes to mind is Author preview feature. How authors would be able to “preview” the pages in such a setup where the presentation layer is NOT available in AEM. Any other challenges and how did you go about solving this would be great insight.

Thanks
Ashish

[Kunal_Gaba_]

This is a good question. I would suggest that you should not use AEM only as a content store in this case. You can model/design your Angular application in AEM in such a way that authors can preview the content in authoring mode as well as edit them as they do for regular web sites. 

Key things to consider while designing- 

1. Model your application in AEM on the same lines you model your website for authors. They should have the capability to add new pages, add new components, delete components and move pages around.They should have the capability to link multiple pages of your application. And they be able to preview and edit the application in the same context it is rendered to the end user. 
2. Do not hard code any page/fragment URLs (or routing URLs) in the Angular JS code. In AEM authors can at run time change the page names, activate/deactivate and delete pages. Therefore, you need to make sure that the routing definition of Angular is dynamically generated. 
3. A page in Angular or a fragment can be composed of multiple AEM components which themselves can be Angular based. What it means is an Angular page can have an Angular image or carousel component which instead of having an HTML view representation  has an Angular HTML template view rep. The template is rendered by the Angular JS as HTML after combining it with the data model or the JSON representation (generated from the dialog properties of the component). 
4. Again instead of hard coding this data binding in the JavaScript it would be good to generate it dynamically as authors should have the capability to add/delete component from the application pages. 
5. You may need to handle scenarios of authoring mode versus the preview mode in your Angular business logic. So, inject the wcmmode variable in the Angular JS controller scope. 

All the above points are factored in by the default sample reference Angular application in AEM 6.1 which dynamically generates the routing definitions and also the data bindings. And it also allows authors to edit content in the same context as it is rendered.

You can see the documentation here - https://docs.adobe.com/docs/en/aem/6-1/develop/mobile-apps/apps/single-page-applications.html . This documentation does not provide more information about the design but if you see the default application code in AEM you will come to know how it has been designed- http://localhost:4502/cf#/content/phonegap/geometrixx-outdoors/en/home.html. Also check the same application in publish context -  http://localhost:4503/content/phonegap/geometrixx-outdoors/en/home.html

[AshishSPanwar-a]

Thanks for detailed response Kunal,

The presentation layer is not yet finalised. It could be anything from Angular, ReactJS to any just about anyother framework. Since the choice of presentation framework could evolve to anything, we would like to focus on AEM acting as a content authoring, storage and delivery layer. There are other core systems (apart from AEM) which the app would need to talk to. And the fact that an entirely separate team would be owning the presentation stack. This decoupled architecture has benefits in that regard.

There already are AEM projects that use similar decoupled setup. I'm looking for any tradeoffs that would be made when going into such a design choice. Staying clear of any gotchas.

- Ashish

[smacdonald2008]

I agree with kunal -- ". I would suggest that you should not use AEM only as a content store in this case"

It sounds like your design choice is a standard web server app and  you are only using AEM as a data store. Using this approach, you are not taking advantage of AEM authoring/publishing capabilities. You can still use AEM for authoring sites as well as using Angular to build components used in the site. Lokesh - one of our top community members submitted code that shows use of Angular with AEM. See: 

https://helpx.adobe.com/experience-manager/using/vanitypath.html

Using AEM only for storing data is not a good design choice for AEM. Its much better to use full capabilities of AEM.