Micro Frontends over UI Monoliths (Wolf Schlegel und Niko Hellwig)
Gleiche Gründe wie bei der Entscheidung für Microservice gegenüber Monolithen:
- Teamgröße
- Skalierbarkeit
- Wartbarkeit
- Unabhängigkeit bei Deployments
Wie durch die obige Grafik verdeutlicht, verfügt ein Headful Microservice über einen eigenen "UI-Kopf". Dies bringt einige Implikationen mit sich:
Der Klärungsbedarf sinkt gegenüber einer headless Lösung, wo ein einzelnes UI Team Inhalte abstimmen und umsetzen muss. Dieses Team kann sich als Flaschenhals entpuppen. Die Schlussfolgerung weniger eng gekoppelte Teams bedeuten weniger Abhängigkeiten gilt also auch für UI!
Bezüglich Technologieabhängigkeit zwischen den Teams, muss Folgendes bedacht werden: Ein gemeinsames UI setzt zumindest auf dem Basislevel eine gemeinsame Technologiewahl voraus.
Zentral ist aus unserer Sicht, dass hier ein Trade-Off aufkommt: User experience vs time to market
Ein koherente User Experience lässt sich leichter in einer headless Lösung realisieren, da hier ein UX-Expertenteam eine microservice-übergreifende Gesamtvision realisieren kann. Die time to market hingegen wird verbessert, wenn man eine headful Lösung einsetzt.
Die Service API bildet die Fachlichkeit ab und ist daher vergleichsweise stabil, wenn man die Häufigkeit betrachtet mit der Änderungen auftreten.
Eine ähnliche Aussage wie die von Herrn Drotbohm: Man möchte keine Backend-Applikation für eine bestimmte Form des Frontends schreiben.
Uns wurden einiger Vor- und Nachteile dreier oft genutzten Methoden zur Kommunikation zwischen Frontend und Backend für Micoservices vorgestellt:
- Frontends to Backends
- Mehr Datenverkehr, da Internet verwendet wird
- Backend direct
- Weniger Datenverkehr
- Asynchron
- Backends for Frontends Schicht
- BFF dürfen keine Business Logik beinhalten --> Dienen nur der Zusammenführung von Komponenten
- Decomposed UI
- Besteht aus Bestandteilen aus allen Microservices
- Shared UI
- Teams können eigene UI Komponenten entwerfen, die in einem UI an unterschiedlichen Stellen eingesetzt werden können (Beispiel Widgets)
- Re-use versus Decomposition
- Je fachspezifischer eine Komponente wird, desto schwieriger wird eine Wiederverwendbarkeit
- Nicht komplizierter machen, als es nötig ist.
- Entscheidungshilfen für, oder gegen Wiederverwendbarkeit:
- Der selbe Bounded Context? Ja, dann Re-use
- Die selben Users and Needs? Ja, dann Re-use
- Kosten der Kopplung? Abwägen wie viel technische Abhängigkeit noch gut für das Unternehmen ist?
- Reuse versichert Konsistenz (mit dem Preis der Kopplung)
- Funktionale Dekomposition ermöglicht Autonomie
- Immer auf den Unternehmenswert achten
- Auf die Microservice Envy achten: Braucht das Unternehmen Microservices?
- Immer der Domäne folgen