Angular als “Multi-Page-App” in den Bloomreach brXM integrieren

Teil 1/2 der Blogreihe zum Thema Website-Bau mit Bloomreach

Eine Webseite mit dem Bloomreach Experience Manager (brXM) unseres starken Technologiepartners Bloomreach zu bauen bringt viele Vorteile, damit sie den Anforderungen der heutigen Webwelt entspricht. So sind dynamische Inhalte, die man zum Beispiel mit Angular realisieren kann, Pflicht. Bei der Umsetzung einer kompletten Seite mit Angular gibt es jedoch diverse Herausforderung zu meistern. Gibt es beispielsweise eine große bestehende Seite, kann diese oft nicht einfach abgelöst werden oder es sollen nur kleine Teile dynamisch gemacht werden. Hinzu kommt möglicherweise, dass das zuständige Team in der Vergangenheit hauptsächlich mit klassischen Technologien gearbeitet hat.

Angular für „Multi-Page-Applications“

Daher möchten wir einen Ansatz vorstellen, wie man nicht nur eine einzelne Seite in Angular umsetzen, sondern mehrere alleinstehende Seiten dynamisch und modern gestalten kann, ohne gleich die gesamte Seite neu implementieren zu müssen. Angular ist für Single-Page-Applications (SPAs) optimiert, mit wenigen Handgriffen lässt es sich allerdings auch dafür nutzen, mehrere Anwendungen innerhalb einer Seite darzustellen, eine „Multi-Page-Application“ sozusagen. Lazy Loading und gemeinsam genutzte Code-Teile sind sogar gleich inklusive!

Angular als “Multi-Page-App” in den Bloomreach brXM integrieren

Der Bloomreach Experience Manager (brXM) als CMS

In diesem Beispiel wird als CMS der brXM verwendet. Dabei werden wir die standardmäßig vorhandene REST-Schnittstelle für Content nutzen. Zudem kommen eine aktuelle Java-Version, sowie Maven zum Einsatz. Über das Frontend-Maven-Plugin bekommt man einen One-Command-Build mitgeliefert. Für Angular benötigen wir Node.js als Build-Umgebung. Ansonsten werden für diese Lösung aber keinerlei Plugins verwendet. Wir gehen für diesen Artikel von grundlegenden Kenntnissen des brXM, Angular und Maven aus.

Grobarchitektur

Prinzipiell ist es nicht schwierig, Angular in ein bestehendes Portal einzubinden. Man fügt das <app-root>-Tag ein, integriert die nötigen JavaScript-Dateien und schon kann man auch in einer bestehenden Seite Angular nutzen. Dann hat man keine Single-Page-Application (SPA) im eigentlichen Sinne, sondern eine "Single Application", eine einzelne, alleinstehende Anwendung innerhalb des Portals. Dies ist auch ohne weiteres mehrfach umsetzbar; in Form von mehreren, einzelnen Angular-Anwendungen innerhalb eines Webauftritts. Diese Anwendungen wissen dann nichts voneinander, was schnell zu Code-Duplikaten führt und sie können auch nur ihren kleinen, beschränkten Bereich abbilden.

Denn bei der Integration von Angular in eigentlich jedes CMS gibt es einen Knackpunkt, an den man schnell stößt: Das CMS verwaltet die URLs. Angular aber, wenn es als vollwertige SPA genutzt wird, macht das auch. Das verhindert in diesem Fall den einfachen Weg, alle Angular-Apps zusammen zu werfen und eine richtige SPA daraus zu machen. Damit ist auch der direkte Weg zu hilfreichen Features wie Lazy Loading versperrt. Dazu aber später mehr. Wer dennoch den Weg beschreiten möchte, seine gesamte Webseite als SPA zu realisieren, sollte sich die SPA-Schnittstelle von Bloomreach einmal genauer anschauen.

Abbildung 1: Gesamtarchitektur

Es gilt also, eine Möglichkeit zu finden, wie man das URL-Management im CMS belässt, aber gleichzeitig mehrere Anwendungen innerhalb einer Angular-App bereitstellt. Der Grundgedanke, um dieses Ziel zu erreichen, ist, den <app-root>-Tag so zu erweitern, dass er - je nachdem mit welchen Parametern er aufgerufen wird - unterschiedliche Module zur Verfügung stellt. Dank webpack bietet Angular CLI beim gewöhnlichen URL-Management über Angular zusätzlich noch die Funktion, dass der Code automatisch in einzelne „Chunks" gesplittet wird. Dabei handelt es sich um fertig kompilierte JavaScript-Dateien, die nur den Code enthalten, der im aktuellen Kontext genutzt wird. Das spart Übertragungszeit beim Laden der Seite und, dank eines kleinen Kniffs, können Sie das in unserer Lösung direkt mitnutzen.

Abbildung 2: Detailarchitektur der Angular-Integration

Das obige Architekturbild beschreibt diese Lösung in groben Zügen. Das URL-Management wird durch verschiedene Selektoren ersetzt, die in die entsprechende FTL-Datei in den brXM eingebunden werden. So kann der Rahmen der Seite wie Navigation, Footer und ähnliches wie gewohnt über das CMS ausgespielt werden. Die jeweiligen Selektoren verweisen dann auf getrennte Module im Angular Code. Jede App hat ihr eigenes Modul und zusätzlich kann es noch ein „shared" Modul geben, das von allen Apps genutzt werden kann. So wird Code-Duplizierung vermieden. Auf der Seite, auf der dann beispielsweise die App aus Modul 1 eingebunden wird, werden nur der Code dieses Moduls und der „shared" Code heruntergeladen. Der Code von Modul 2 und den weiteren Modulen muss nicht übertragen werden.

Im zweiten Teil dieses Artikels nächste Woche werde ich anhand von Codebeispielen zeigen, wie diese Lösung umgesetzt wurde, wie genau die App-Selektoren aufgebaut sind und wo dann wieder ein Teil des URL-Managements von Angular ins Spiel kommt, um die „Chunks" automatisch generieren zu lassen.