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

Inhaltsverzeichnis

Legacy: Ein Wort, das einem den Schauer über den Rücken treibt. Viele versuchen Projekte, deren Methoden das Wort enthhält, zu meiden – schließlich möchte man nicht mühevoll Know-how aufbauen, das veraltet ist. Das Problem ist nur, dass Verfahren immer schneller in den Status "Legacy" driften. Gerade im Umfeld von Single-Page-Applikationen, bei denen ständig neue JavaScript-Frameworks aufkommen, ist das ein besonderes Problem. Das gilt vor allem für jene, die langfristig zu pflegen und erweitern sind. Eine Lebensdauer von 10 bis 15 Jahren ist im Enterprise-Umfeld keine Seltenheit. Wie geht man damit um?

Microservices

Im Backend kennt man hierfür eine Antwort: Microservices. Die Idee ist an und für sich simpel und alles andere als neu: Anstatt einer großen Anwendung, die alles kann, schafft man viele kleine. Sie tauschen zwar falls nötig untereinander Nachrichten aus, funktionieren aber auch, wenn der "Nachbar" mal nicht verfügbar ist. Unterschiedliche Teams können sich nun um die einzelnen Microservices kümmern und dafür die geeignetsten Werkzeuge einsetzen. Die Teams können autark arbeiten, ohne sich ständig mit anderen Teams abstimmen zu müssen. Außerdem können sie ihren Microservice unabhängig von anderen Teams in Produktion setzen. Diesen Vorteil erkaufen sie sich mit einem hochgradig verteilten System. Es gilt, unter anderem über Fehlertoleranz, Schnittstellen und Datenkonsistenz über Servicegrenzen hinweg nachzudenken. Überträgt man die Idee in die Welt der User Interfaces (UI), spricht man neuerdings von Micro-Frontends oder Micro-Apps.

Micro-Apps

Mehrere kleine Apps statt einer großen zu entwickeln, ist zunächst keine Hexerei. Die Grenzen zwischen den Apps müssen gut definiert sein. Dabei hilft unter anderem Domain-driven Design mit der Idee des Bounded Context. Salopp gesprochen, handelt es sich um eigenständige Bereiche, die von anderen isoliert sind und ihr eigenes Datenmodell haben.

In der Regel arbeiten in unterschiedlichen Bereichen auch unterschiedliche Fachexperten. Eine Anwendung zum Buchen von Flügen könnte man zum Beispiel nach den Aspekten Passagiere, Flüge und Buchungen unterteilen. Daneben ist es häufig wünschenswert, dem Benutzer die einzelnen Micro-Apps als großes Ganzes anzubieten. Das stellt Entwickler von Single Page Applications (SPA) vor eine Herausforderung, denn die vorliegenden Frameworks unterstützen das nicht. Es gilt, selbst eine Variante zu finden. Die nachfolgenden Abschnitte zeigen ein paar Möglichkeiten auf.

Hyperlinks

Die einfachste Lösung für das Zusammenfügen unterschiedlicher SPAs ist der Einsatz von Hyperlinks. Große Konzerne machen es mit ihren Produktsuiten vor, beispielsweise Google mit Google Maps (Abbildung 1). Es handelt sich um eine Micro-App, die auf eine Aufgabe spezialisiert ist. Außerdem bietet sie über einen Sushi-Menü-Button verschiedene Hyperlinks, die auf andere Anwendungen der Produktsuite verweisen.

Leider hat der einfache Ansatz auch einen enormen Nachteil: Das Gesamtsystem ist keine SPA mehr. Das bedeutet, dass der Anwendungszustand beim Wechsel der Anwendung verloren geht, sofern die Anwendung ihn nicht explizit sichert. Außerdem muss der Benutzer immer wieder eine neue Seite laden. Genau das möchten Entwickler mit Single Page Applications zur Steigerung der Benutzerfreundlichkeit verhindern. Glücklicherweise können Entwickler die Nachteile in einigen Fällen vernachlässigen: Vor allem, wenn Benutzer nur selten die App wechseln beziehungsweise die einzelnen Apps in eigenen Tabs öffnen können, ohne dass es sich komisch anfühlt.