Integrate Angular as a “multi-page app” into Bloomreach Experience Manager (brXM) - Part 1

​ Jan Pralle

​ 2020-05-07

This article was originally published in German by Jan Pralle on https://diva-e.com/.

 Part 1/2 of the blog series on website construction with Bloomreach

 

Building a website with the Bloomreach Experience Manager (brXM) from our strong technology partner Bloomreach offers many advantages so that the website exceeds the requirements of today's web world. For example, dynamic content that could be realized with eg. Angular is easily done. When implementing a complete page with Angular, however, there are various challenges to be mastered. For example, if there is a large existing page, it can often not be easily replaced or only small parts should be made dynamic. In addition, the team responsible has mainly worked with classic technologies in the past.

 

Angular for "multi-page applications"

Therefore, Dive-E would like to present an approach on how not only to convert a single page in Angular, but how to design several standalone pages dynamically and modernly without having to re-implement the entire page. Angular is optimized for single-page applications (SPAs), but with a few simple steps it can also be used to display several applications on one page, a "multi-page application", so to speak. Lazy loading and shared code parts are even included!

 

The Bloomreach Experience Manager (brXM) CMS

In this example, brXM is used as the CMS. We will use the standard REST interface for content. In addition, a current Java version and Maven are used. Via the frontend maven plugin, you get a one-command build included. For Angular, we need Node.js as a build environment. Otherwise, no plugins are used for this solution. We assume basic knowledge of brXM, Angular and Maven for this article.

 

High-level architecture

In principle, it is not difficult to integrate Angular into an existing portal. You insert the <app-root> tag, integrate the necessary JavaScript files and you can use Angular in an existing page. Then you don't have a single page application (SPA) in the actual sense, but a "single application", a single, standalone application within the portal. This can also easily be implemented multiple times; in the form of several, individual Angular applications within one website. These applications then know nothing about each other, which quickly leads to code dublication, and they can only cover their small, restricted area.

Because when integrating Angular into virtually every CMS, there is a sticking point that you quickly come across: the CMS manages the URLs. But Angular, if it is used as a full SPA, does the same. In this case, this prevents the easy way to throw all Angular apps together and make a real SPA out of them. This also blocks the direct path to helpful features such as lazy loading. More on that later. If you still want to walk the path of realizing your entire website as a SPA, you should take a closer look at the Bloomreach SPA interface .

Pralle, J. Figure 1: Overall architecture, (2020). Diva-E, Retrieved from https://a.storyblok.com/f/67091/400x450/ebdfe22647/visual-angular-2.png

 

So it is important to find a way to leave the URL management in the CMS, but at the same time to provide several applications within an Angular app. The basic idea to achieve this goal is to extend the <app-root> tag so that - depending on the parameters with which it is called - it provides different modules. Thanks to Webpack, Angular CLI also offers the function of ordinary URL management via Angular that the code is automatically split into individual "chunks". These are fully compiled JavaScript files that only contain the code that is in the current context. This saves transfer time when loading the page and, thanks to a little trick, you can use it directly in our solution.

Pralle, J. Figure 2: Detailed architecture of the Angular integration, (2020). Diva-E, Retrieved from https://a.storyblok.com/f/67091/400x450/ded3ac88bf/visual-angular-3.png

 

The architectural picture above describes this solution on a high level. The URL management is replaced by various selectors, which are integrated into the corresponding FTL file in brXM. The frame of the page such as navigation, footer and the like can be powered as usual via the CMS. The respective selectors then refer to separate modules in the Angular Code. Each app has its own module and there can also be a "shared" module that can be used by all apps. This prevents code duplication. On the page on which the app from module 1 is then integrated, for example, only the code of this module and the "shared" code is downloaded. The code of module 2 and the other modules don’t have to be transmitted.

In the second part of this article, I will use code examples to show how this solution was implemented, how exactly the app selectors are structured and where the other part of the URL management from Angular comes into play, to automatically generate these "chunks”.