Micro-Frontend-Architekturen

In diesem Projektbeispiel von Concept Reply umfasst das Frontend eine Hauptanwendung, in der alle anderen Micro-Frontends enthalten waren. Es war schwierig, Änderungen in einem der Micro-Frontends vorzunehmen, zum Beispiel wenn eine bestehende Komponente überarbeitet werden musste oder neue UI-Komponenten in einem Micro-Frontend erstellt werden sollten.

Das Team musste eine Entwicklungs- bzw. Test-Komponente erstellen, um Änderungen zu erproben. Außerdem benötigt das Micro-Frontend eine andere Struktur, um in anderen Projekten oder zum Testen der Änderungen genutzt werden zu können. Das Micro-Frontend musste manuell erstellt werden und als der Build erfolgreich war, konnte die Test-Komponente wie jedes andere Frontend-Projekt lokal in React/Angular gestartet werden. Das Build manuell auszuführen und anschließend das Projekt erneut lokal zu starten, verlängerte die Entwicklungsdauer. Als die Entwickler die Änderungen ausgeführt haben, testeten sie diese mit der Hauptanwendung. Zwar ist jedes Projekt anders aufgebaut, doch in den meisten Fällen gibt es nach dem Zusammenführen der Features auf der Entwicklungsumgebung einen Release im Entwicklungssystem vor dem Rollout auf die Produktions/ oder Liveumgebung. Nach den Änderungen in einem der Micro-Frontends erstellten die Entwickler eine Pre-Release-Version, die für Tests in der Hauptanwendung verwendet werden konnte. Grundsätzlich wurden die Micro-Frontends als Libraries installiert. Das Team von Concept Reply verwendete die neue Version in der Hauptanwendung, installierte diese und war dann in der Lage, die neuesten Änderungen des Micro-Frontends zu testen.

Generell empfiehlt es sich, einen universellen Stil für bestimmte Layout-Bestandteile wie Formular-Elemente, Schaltflächen etc. zu definieren und diese in anderen Komponenten wiederzuverwenden. Wenn der Stil einer Komponente in einem Micro-Frontend, das einige Stile verwendet oder bestimmte CSS-Stile durch den universellen Stil überschreibt, angepasst werden muss, geht es schneller, die Änderung auszuführen und den gesamten Entwicklungsprozess abzuschließen.

Die Weiterentwicklung von Frontend-Frameworks schreitet so schnell voran, dass in kürzester Zeit neue Hauptversionen erscheinen. Es empfiehlt sich, Upgrades an Frameworks laufend durchzuführen, um die neuesten Änderungen und Performance-Verbesserungen nutzen zu können. Doch das kann mit einer Micro-Frontend-Architektur sehr mühsam sein. Dafür muss ein Versions-Upgrade für jedes Micro-Frontend erfolgen. Zudem müssen die Probleme aus neuen Updates behoben und eine Release-Version mit dem neuesten Upgrade erstellt werden. Dieser Prozess muss für alle Micro-Frontends wiederholt werden. Daher kann das Upgraden mit einem großen Aufwand verbunden sein. Dieses Problem lässt sich umgehen, indem Upgrades auf die nächste große Version mit dem Frontend-Framework durchgeführt werden.

Concept Reply hat an verschiedenen Frontend-Projekten gearbeitet und möchte daher die eigenen Erfahrungen mit vergleichsweise komplexen Frontends teilen. Bei einem Projekt arbeiteten viele Entwickler an unterschiedlichen Merkmalen und passten mehrere Bereiche des Frontends an – mit einer negativen Erfahrung. Diese traten mit dem Micro-Frondend-Ansatz nicht auf. Die Entwicklung erfolgte viel schneller, da keine Änderungen an einem Micro-Service vorzunehmen waren und es nicht erforderlich war, einen Build oder eine Pre-Release-Version zu erstellen. Zudem konnten die Experten keine Nachteile für den Gesamtprozess von der Entwicklung, über das Testen bis hin zur Bereitstellung in der Produktion feststellen. Eine nahtlose und effiziente Entwicklung konnte schnell und einfach erreicht werde, indem man sich an bestimmte Entwicklungsprinzipien mit geeigneten Programmiervorgaben hielt. So konnten auch die Codequalität und eine pünktliche Bereitstellung gewährleistet werden.