© rozmarin/shutterstock.com
Ihr 6+1-Punkte-Plan zur Erstellung einer Microfrontend-Shell

Der Teil und das Ganze


Microfrontends sind derzeit ein viel diskutiertes Thema. Nach dem Vorbild von Microservices wird dabei ein großes Frontend auf mehrere kleine aufgeteilt. Dadurch sollen einzelne Teams autark arbeiten und sogar eigene Technologieentscheidungen treffen können. Während diese Idee im Kern simpel ist, ist es die konkrete Umsetzung leider nicht. In diesem Artikel fasse ich die in verschiedenen Projekten gesammelten Erfahrungen in 6 + 1 Punkten zusammen und zeige, wie sich eine Microfrontend-Shell umsetzen lässt.

Bei unserem Beispiel handelt es sich um eine Anwendung, die bei Bedarf die einzelnen Microfrontends lädt (Abb. 1). Anwender erhalten so den Eindruck, mit einer großen, integrierten Softwarelösung zu arbeiten. Den Quellcode dafür stelle ich in meinem GitHub-Account [1] zur Verfügung.

steyer_angular_1.tif_fmt1.jpgAbb. 1: Shell, die ein Microfrontend (rot umrahmt) geladen hat

Vorbedingungen

Alle Architekturstile haben bekanntlich ihre speziellen Vor- und Nachteile – das gilt auch für Microfrontends. Zudem erfordern diese einen gewissen Mehraufwand, weil die aktuellen Frameworks nicht auf sie ausgerichtet sind. Doch zunächst ein paar Vorteile:

  • Teams werden entkoppelt.

  • Teams können autark arbeiten und eigene Technologie- sowie Architekturentscheidungen treffen.

  • Separates Deployment: Teams müssen nicht aufeinander warten, bis sie ein neues Feature in Produktion setzen können.

Wie man sieht, geht es bei Microfrontends besonders um organisatorische Aspekte. Man erhofft sich mehr Agilität, indem jedes Team möglichst autark arbeiten kann. Ein angenehmer Nebeneffekt ist, dass einzelne Programmteile mit verschiedenen Technologien gebaut werden können. Das macht niemand, weil es hip ist, sondern weil große Softwaresysteme mit einer Lebensdauer von 10 bis 20 Jahren oder mehr so manche Technologie überleben.

Wenn diese Ziele nicht entscheidend für den Erfolg der Softwarelösung sind, sollte man sich allerdings gut überlegen, ob man die negativen Seiten dieses Architekturstils im Kauf nehmen möchte. Zu den Nachteilen gehören die folgenden Aspekte:

  • Keine Framework-Unterstützung: Aktuelle SPA Frameworks sind nicht auf Microfrontends ausgelegt. Teams müssen sich diese Unterstützung selbst bauen, was sowohl eine tiefe Kenntnis der eingesetzten Frameworks als auch der JavaScript-Plattform an sich erfordert.

  • Abhängig von der gewählten Implementierungsvariante können sich größere Bundles ergeben.

Die größeren Bundles folgen unter anderem daraus, dass jedes Microfrontend seine eigenen Frameworks mit...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang