© nep0/Shutterstock.com
Microfrontends mit Angular im Praxiseinsatz

Architektur für agile Teams


Wir haben mehrere namhafte Unternehmen gefragt, warum und wie sie Microfrontends nutzen. Ein Mittelständler gibt Auskunft, warum er sich bewusst dagegen entschieden hat.

In den letzten Jahren habe ich einige Kunden bei der Umsetzung von Microfrontends mit Angular unterstützt. Dabei unterscheiden sich die Realisierungen teilweise beträchtlich voneinander. Der Grund dafür sind die vielen verschiedenen Implementierungsvarianten von Microfrontends, mit denen unterschiedliche Vor- und Nachteile einhergehen. Diese müssen im konkreten Fall gegen die vorherrschenden Architekturziele abgewogen werden.

In diesem Artikel zeige ich Implementierungsvarianten sowie deren Konsequenzen anhand von praktischen Beispielen auf. Dazu habe ich einige Kunden befragt – fünf dieser Gespräche präsentiere ich hier nach einem kurzen Überblick. Um zu unterstreichen, dass Microfrontends nicht immer passend sind, gibt es am Ende noch einen Fall, in dem sich ein Unternehmen gegen diesen Architekturstil entschieden hat.

Was sind Microfrontends?

Ähnlich wie bei Microservices im Backend ist die Idee von Microfrontends, mehrere kleine anstatt einer einzigen großen Anwendung zu nutzen. Die Vorteile dieser Art der Modularisierung sind in erster Linie nicht technischer, sondern organisatorischer Natur, da sie weitgehend autarke Teams ermöglichen. Jedes Team kümmert sich um sein eigenes Microfrontend und soll sich nur wenig mit anderen Teams abstimmen. Das bedeutet auch, dass Technologiestacks sowie Architekturstile, die am besten zur jeweiligen Domäne passen, zum Einsatz kommen können. Einen firmeninternen Technologiemix führt man natürlich nicht aus Jux und Tollerei ein. Bei Softwaresystemen und Produktsuiten, die über eine Dekade oder länger hinweg entwickelt werden, ist es jedoch durchaus sinnvoll, zwischendurch auf aktuelle Stacks wechseln zu können. Ein weiterer Vorteil von Microfrontends ist die Möglichkeit, jedes Frontend separat bereitstellen zu können. Teams blockieren sich also nicht mehr gegenseitig und das bringt Agilität.

Wo sind die Herausforderungen?

So verlockend diese Vorteile auch klingen mögen – problemlos umsetzbar sind sie nicht. Das liegt unter anderem daran, dass aktuelle SPA Frameworks sowie Bundling-Lösungen (noch) nicht mit dieser Idee im Hinterkopf geschaffen wurden. Das bedeutet, dass die Teams ggf. selbst Infrastrukturcode zur Orchestrierung der einzelnen Microfrontends entwickeln müssen [1]. Außerdem gilt es, verschiedene Fragen zu klären, z. B., wie die einzelnen Frontends dem Benutzer als großes Ganzes präsentiert werden sollen, aber auch, wie die Kommunikation zwischen den Frontends erfolgen kann. Zudem benötigt man eine Art Single Sign-on für alle Einzellösungen. Daneben müssen die Teams entscheiden, ob und wie Komponenten zwischen den Microfrontends zu teilen sind. Gerade das ist ein sehr delikates Thema, denn während man gerade komplexe Komponenten wiederverwenden möchte, widerstrebt solch ein Austausch der grundlegenden Idee hinter Microservices, nämlich Abhängigkeiten zwischen Teams zu verhindern.

Eine ideale Lösung gibt es hier wohl nicht. Vielmehr müssen anhand der verschiedenen Architekturanforderungen passable Ansätze gefunden werden, die mehr Vor- als Nachteile mit sich bringen. Dieses Dilemma sollte Softwarearchitekten jedoch ohnehin bekannt sein. Deswegen zielen auch einige der nachfolgend gestellten Fragen sowohl auf die gewählten Maßnahmen wie auch auf die beobachteten Konsequenzen – sowohl in positiver als auch in negativer Hinsicht – ab.

AGFA Healthcare

Welche Art von Anwendung setzen Sie um?

Wir implementieren ein Krankenhausinformationssystem bzw. ein klinisches Informationssystem, das alle relevanten Workflows im klinischen Ablauf von Ärzten, Pflegekräften und anderen Care-Providern abbildet (Abb. 1).

steyer_microfrontends_1.tif_fmt1.jpgAbb. 1: AGFA Healthcare – die gestrichelten Linien deuten verschiedene Microfrontends an
steyer_microfrontends_2.tif_fmt1.jpgAbb. 2: AGFA Healthcare – die Ansicht setzt sich aus Bestandteilen mehrerer Microfrontends zusammen

Warum haben Sie sich für eine Microfrontend-Architektur entschieden?

Es handelt sich bei unserer Lösung um eine Produktsuite, bestehend aus mehreren individuellen Teilprodukten, die dem Benutzer als großes Ganzes (Composite Application) präsentiert werden sollen und verschiedene Workflows abbilden. Außerdem wollten wir ein Baukastensystem zur Herstellung von Composite-Lösungen für unterschiedliche Märkte. Wir benötigten zudem einen Ansatz, der auch bei vielen Teams mit einer verteilten Entwicklung funktioniert.

Die Architektur erleichtert ein unabhängiges Deployment von Teilen der Applikation. Der Umfang eines Updates kann dadurch reduziert werden, und es muss nicht immer das ganze Frontend ausgetauscht werden. Der Ansatz sollte unterschiedliche Entwicklungsgeschwindigkeiten in verschiedenen Teams und eine klare Abgrenzung von Medizinprodukten zu Nichtmedizinprodukten ermöglichen. Zukunftssicherheit war uns hierbei ebenso wichtig, da sich unterschiedliche Frontend-Technologien in unterschiedlichen Generationen zu einem Gesamtprodukt zusammenfassen lassen.

Wie haben Sie diese Architektur umgesetzt?

Zum einen kamen iFrames zum Einsatz, u. a., um bestehende Funktionalitäten einbinden zu können. iFrames bieten eine sehr gute Isolation der einzelnen Microfrontends. Zum anderen haben wir für die neueren Produktentwicklungen bereits auf Web Components gesetzt.

Inwieweit sind die Vorteile, die Sie sich von dieser Architektur erhofft haben, eingetreten?

Die einzelnen Produkte können möglichst unabhängig voneinander von verschiedenen Teams entwickelt werden. Außerdem führt der Ansatz zu klaren Schnittstellen zwischen den einzelnen Funktionalitäten. Auch die Wiederverwendbarkeit ist sehr gut. Durch die klaren Schnittstellen konnte auch ein hoher Grad an organisatorischer Skalierbarkeit erreicht werden (viele unabhängige Teams), da die Aufgaben besser verteilbar sind.

Welche Herausforderungen sind aufgetreten?

Wir mussten Code schreiben, um die einzelnen iFrames zu koordinieren und damit einhergehende Usability-Probleme zu kompensieren. Außerdem mussten wir ein Framework für die übergreifende Kommunikation der einzelnen iFrames erstellen, welches z. B. Kontextänderungen an alle iFrames bzw. Web Components propagiert bzw. Kontextänderungen entgegennimmt und propagiert.

Wir haben eine umfängliche UX- und UI-Guideline erstellt, damit ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang