iframes – der heilige Gral bei verteilten Webanwendungen

Microservices und verteilte User Interfaces stellen hohe Anforderungen an die technische Integration via Hyperlinks, Single-Page-Applikationen oder Web Components. Speziell in komplexen Systemumgebungen mit vielen Entwicklerteams können iframes ihre Stärken ausspielen – sofern das Handling der Kommunikation gelingt.

Architektur/Methoden  –  108 Kommentare

Eine große Herausforderung in der Umsetzung einer Microservice-Architektur liegt darin, den vertikalen Schnitt durch alle Ebenen – Benutzeroberfläche, Geschäftslogik und Datenhaltung – zu ziehen. Dabei fällt gerade die Zerlegung der grafischen Benutzeroberfläche (GUI) schwer. Es entstehen häufig Systeme, deren Backend zwar in Microservices aufgeteilt ist, die aber nur einen einzigen vorgeschalteten Frontend-Monolithen besitzen (siehe Abbildung 1).

Dadurch entfaltet die Microservice-Architektur nicht ihr volles Potenzial. Die Entwicklung des Frontend-Monolithen erfolgt häufig durch mehrere Teams, was zu hohem Abstimmungsaufwand führt, der sich schnell als Nadelöhr in der Entwicklung entpuppt. Deshalb sollte jeder Microservice entsprechend seiner Aufgabe eine eigene Benutzeroberfläche ausliefern. Da sich für den Endanwender in der Regel ein System aus mehreren Microservices zusammensetzt, ist es ratsam, einzelne Benutzeroberflächen im Sinne einer guten Usability in eine gemeinsame Oberfläche (aus einem Guss) zu integrieren.

Vom Frontend-Monolithen zur durchgängigen Microservice-Architektur (Abb. 1) (Bild: Volkswagen AG)

Anforderungen an die Integration verteilter Benutzeroberflächen

Bei der Integration verteilter Benutzeroberflächen sind eine Reihe von Anforderungen zu berücksichtigen:

1. Look & Feel
Ein einheitliches Erscheinungsbild mit entsprechendem "Look & Feel" ist Grundvoraussetzung für eine hohe Usability. Das erfordert eine gewisse Disziplin beim Gestalten der GUI-Module, da alle Teile am Ende in einem Gesamtsystem auch rein optisch zusammenpassen und eine homogen wirkenden Anwendung ergeben sollen. Dazu sind oftmals gewisse Stilvorgaben (beispielsweise in Form von CSS-Dateien oder Grafiken) über die einzelnen Komponenten hinweg auszutauschen. Ein einheitliches Erscheinungsbild ist allerdings nicht immer notwendig. Es kommt im Einzelnen auf das Nutzerverhalten an. Sobald ein Anwender mehrere Module nutzt, sollte die Benutzerführung und das Styling möglichst gleich sein, andernfalls leidet die Bedienbarkeit des Systems.

2. Unabhängige Deploybarkeit
Es ist empfehlenswert, dass sich die einzelnen Benutzeroberflächen der Microservices unabhängig voneinander deployen lassen. Insbesondere bei großen Systemen spielt es eine wichtige Rolle, dass im Vorfeld weder Quellcode noch Softwareartefakte auszutauschen sind. Wünschenswert ist eine dynamische Integration der Oberfläche zur Laufzeit.

3. Austausch von Zuständen
Für die Zusammenführung der einzelnen Komponenten sind die Schnittstellen zu definieren, um einen reibungslosen Nachrichtenaustausch beispielsweise von Zustandsinformationen zu gewährleisten.

4. Technologieunabhängigkeit
Jede Benutzeroberfläche der Microservices sollte sich technologieunabhängig umsetzen lassen. Darüber hinaus ist es ratsam, dass auch die Integration verschiedener Webtechnologien (wie Angular oder React) innerhalb eines Anwender-Frontends möglich ist. Jedes Team entscheidet dann eigenständig über die praktische Umsetzung des eigenen Frontend-Teils. Dadurch entfällt die Notwendigkeit einer zentralen Vorgabe, die gegebenenfalls für den spezifischen Anwendungsfall ungeeignet ist oder für die innerhalb des Teams die nötige Wissensbasis fehlt.

5. Isolation
Darüber hinaus empfiehlt sich bei Bedarf, die Benutzeroberflächen voneinander zu isolieren. Ein vom Drittanbieter angebotener Service wie Social Media oder Werbung wird in einer Sandbox eingebettet, während ein Service des eigenen Unternehmens mehr Vertrauen erhält.