Raus aus der Legacy-Falle: Single Page Applications und Micro-Apps

Shell für Micro-Apps

Kommt man mit Hyperlinks nicht zum Ziel, muss häufig eine Shell her. Damit ist eine Anwendung gemeint, die die einzelnen Micro-Apps bei Bedarf lädt. Abbildung 2 zeigt ein Beispiel einer Shell, die gerade eine Angular-Micro-App (roter Rahmen) geladen hat. Wie die Icons veranschaulichen, nutzt die Micro-App Widgets von anderen Apps, die auch mit anderen Frameworks geschrieben sind. Weitere Informationen dazu finden sich in einem Beispiel des Autors.

Abb. 2: Schematische Darstellung einer Shell

Die Shell lädt die Micro-Apps nicht nur, sondern zeigt sie auch zum richtigen Zeitpunkt an. Beispielsweise könnte eine Micro-App, die sich um die Verwaltung von Passagieren kümmert, den gerade ausgewählten Passagier an andere Micro-Apps weiterreichen. Um Abhängigkeiten zu vermeiden, kommunizieren Micro-Apps nur selten miteinander. Zur Sicherstellung einer losen Kopplung bietet sich der Einsatz von Messaging an. Das bedeutet, dass jede App bei bestimmten Ereignissen eine Nachricht veröffentlicht. Ob sich andere dafür interessieren oder nicht, sollte ihr egal sein. Schon gar nicht sollte sie eine bestimmte Antwort erwarten, denn das führt zu Abhängigkeiten und verringert die Stabilität des Gesamtsystems. Für die Implementierung der Shell stehen mehrere Ansätze zur Verfügung, wobei jeder davon seine ganz eigenen Vor- und Nachteile hat.

Integration über iframes

Eine einfache Strategie zur Umsetzung einer Shell sind iframes. Auch wenn es sich dabei wohl um eine der unbeliebtesten Web-Techniken handelt, haben sie Vorteile: Sie erlauben die Integration von Legacy-Anwendungen, egal ob sie dem Single-Page- oder dem klassischen Multi-Page-Ansatz folgen, und sie bieten die beste Isolation, die man in einer Webanwendung haben kann. Isolation bedeutet, dass eine Micro-App einer anderen Micro-App nicht in die Quere kommt. Sie können sich nicht gegenseitig ausspionieren oder manipulieren. Außerdem wirken sich Fehler sowie Styles einer Micro-App nicht auf die anderen aus. Gerade das kann bei Applikationen, deren Bestandteile verschiedene Dienstleister entwickeln, interessant sein.

Eine wohldefinierte Kommunikation zwischen iframes lässt sich über eine standardisierte API postMessage durchführen. Sie erlaubt das Versenden von Nachrichten, wobei es dem Nachrichtenempfänger offen steht, Nachrichten nach deren Herkunft oder Inhalt zu filtern. Um zu verhindern, dass der iframe eine eigene Scrollbar bekommt, muss die Shell ihn regelmäßig an seinen Inhalt anpassen. Das lässt sich über den Austausch von Nachrichten bewerkstelligen: Die Micro-App sendet ihre aktuelle Höhe an die Shell und sie vergrößert beziehungsweise verkleinert den iframe. Das ist keine schöne Umsetzung, aber wenn die aufgezeigten Vorteile überwiegen, kann man sich damit arrangieren. Klar ist aber auch, dass sich iframes nicht für öffentliche Auftritte eignen und auch bei internen Anwendungen möchte man sie vermeiden, sofern man weder deren Isolation braucht noch Legacy-Anwendungen integrieren muss.