Anzeige
Anzeige
How-To

Micro-Frontends: Große Webprojekte modularer entwickeln

Microservices sind ein beliebtes Konzept, um wachsenden Backend-Code in gut ­wart­­bare Teile zu zerlegen. Die zugrunde liegenden Ideen lassen sich auch auf das Frontend ­ausdehnen – für schnellere Softwareentwicklung und bessere Kundenorientierung. ­Die organisatorischen Anforderungen sind allerdings komplex.

Von michael.geers
8 Min.
Artikel merken
Anzeige
Anzeige

(Shutterstock / Aleksandar Karanov)

Frontend-Entwicklung umfasst heute eine große Bandbreite an verschiedensten Bereichen. Neben reiner CSS-Gestaltung spielen Themen wie unterschiedliche Endgeräte, schnelles Ladeverhalten, hohe Interaktivität, Barrierefreiheit, Testbarkeit und Sicherheit eine immer wichtigere Rolle. Um diesen wachsenden Anforderungen gerecht zu werden, hat sich in den meisten Teams die Abgrenzung zwischen Frontend- und Backend-Entwicklern gebildet. Das Idealbild des Fullstack-Developers, der in der Lage ist, auf allen Ebenen der Software zu interagieren, scheint immer schwerer erreichbar zu sein. Javascript-Frameworks wie React, Vue.js und Angular schaffen Abhilfe. Sie bieten dem Frontend-Entwickler Lösungen für viele der beschriebenen Anforderungen. Zudem bringen sie meist ein eigenes Komponentensystem mit, welches Wiederverwendbarkeit gewährleistet und die Organisation des Quellcodes deutlich vereinfacht.

Zu groß für ein Team

Anzeige
Anzeige

Wächst ein Projekt und damit auch das Team, ist irgendwann der Punkt erreicht, an dem die Weiterentwicklung der Software zäh und anstrengend wird. Änderungen an einer Stelle haben unerwartete Nebenwirkungen an anderer. Niemand hat mehr einen Gesamtüberblick über das Projekt. Technologische Erneuerung wie etwa das Wechseln einer zentralen Bibliothek oder das Upgrade eines Frameworks müssen von langer Hand geplant werden und bergen oft große Risiken.

Hier kommen Microservices ins Spiel. Im Gegensatz zu Monolithen wird Software in kleine, gut handhabbare und eigenständige Services zerlegt. Jeder Service hat eine spezielle Aufgabe und ist einem Entwicklungsteam zugeordnet. Oft ist dieses Zerlegen jedoch nur auf den Backend-Code begrenzt, das Frontend bleibt als Monolith oberhalb der Services erhalten. Um die Kommunikation zu erleichtern, wird zwischen Frontend und Backend gerne noch ein API-Gateway-Layer eingezogen. Er aggregiert die benötigten Daten von den jeweiligen Services und stellt sie dem Frontend für die Anzeige zur Verfügung.

Anzeige
Anzeige

Bildet das Frontend eine mono­lithische Schicht oberhalb der ­Microservices im Backend, sind einzelne Entwicklungsschritte oft mit hohem Abstimmungsaufwand zwischen den Teams verbunden. (Grafik: Michael Geers, Icons by Freepik from flaticon.com)

Diese Architektur ist momentan sehr populär, bringt aber einige Probleme mit sich: So gibt es nun ein Skalierungskonzept für das Backend, das Frontend bleibt aber weiterhin ein Monolith. Javascript-Frameworks mit eigenem Komponentenmodell verstärken diese monolithische Struktur noch. Am einfachsten entwickelt es sich, wenn alle Teile der Seite mit dem gleichen Framework betrieben werden. Doch die Frontend-Welt bewegt sich schnell. Das Versionsupdate eines Frameworks wird schnell zu einer großen und unangenehmen Aufgabe, wenn die Beteiligten keinen Überblick über die gesamte Applikation haben – von großen Versionssprüngen wie von „Angular 1“ auf „Angular 2“ ganz abgesehen.

Anzeige
Anzeige

Microservices auch­ im Frontend einsetzen?

Der Ansatz, der sich jetzt förmlich aufdrängt, ist die Umsetzung der Microservice-Idee auch im Frontend. Anstatt einer ­großen Single-Page-Applikation baut man mehrere unabhängige Teilapplikationen, die miteinander kommunizieren. Diese sind dann deutlich einfacher zu verstehen. Der Einsatz einer neuen Technologie lässt sich in einem kleineren Rahmen testen. Auch die technische Erneuerung oder Reimplementierung einer Teilapplikation ist so eine leichter umzusetzende Aufgabe als die Big-Bang-Migration der ganzen Site.

Allerdings ist die Idee, neben den Backend-Microservices noch zusätzlich unabhängige Frontend-Microservices einzuführen, recht technisch gedacht und verkompliziert das Gesamtbild. Schaut man mit der Brille eines Produktmanagers auf das  Architekturdiagramm, wird das Problem deutlich: Die organisatorische Komplexität in diesem Modell ist sehr hoch. Um ein neues Feature für den Kunden zu entwickeln, müssten sich die Backend-Entwickler der betroffenen Services, das Frontend-Team und die Verantwortlichen für das API-Gateway untereinander abstimmen. Agile Werte wie „Schnelles Reagieren auf Änderungen“ blieben auf der Strecke.

Anzeige
Anzeige

Micro-Frontends Schnitte aus ­Kundensicht

Das Konzept der Micro-Frontends geht also noch einen Schritt weiter. Eine Anwendung wird nicht in horizontale Stücke – ­Front- end, Gateway, Backend – geteilt, sondern in vertikale. Jede ­Vertikale wird von einem interdisziplinären Team entwickelt, ­welches für den gesamten Stack, von Datenbank bis Benutzer­oberfläche, verantwortlich ist. Es gibt also keine separaten Frontend- und Backend-Teams mehr. Die Teams sind, ähnlich wie bei Microservices, frei in der Wahl ihrer Arbeitsweise und Technologie und können autonom arbeiten. Man kann sich das System wie einen in die Höhe gezogenen Microservice vorstellen: ein Microservice mit eigenem Frontend, andernorts auch als Self-Contained-System bezeichnet.

Im Micro-Frontends-Modell werden Teams und Systeme nicht nach ­technischen Gesichtspunkten aufgebaut, sondern anhand von Kundenbedürfnissen. Jedes Team ist interdisziplinär aufgestellt und entwickelt von Datenbank bis ­Benutzeroberfläche. (Grafiken: Michael Geers, Icons by Freepik from flaticon.com)

Die vertikalen Schnitte werden nicht nach technischen ­Gesichtspunkten, sondern anhand der Kundenbedürfnisse festgelegt. In einem Onlineshop können dies beispielsweise die Phasen des Kaufprozesses sein. Im Schaubild ist ein Beispiel mit drei Vertikalen dargestellt. Team „Entdecken“ hat die Aufgabe, den Kunden bei der Suche nach relevanten Artikeln zu unterstützen, Team „Entscheiden“ stellt ihm alle Artikeldetails für eine Kaufentscheidung zur Verfügung und Team „Bestellen“ führt ihn durch den Bestellprozess. Jedes dieser Teams hat eine klar umrissene Aufgabe, auf die es sich spezialisiert. Der Verantwortungsbereich eines Teams ist deutlich kleiner als bei einem Monolithen. Je nach Größe des Projekts können die Schnitte natürlich auch noch kleiner gefasst werden.

Der Versandhändler OTTO hat 2011 seine E-Commerce-Plattform (Projekt „Lhotse“) nach diesem Konzept neu aufgebaut. Auch Firmen wie Zalando (Project „Mosaic“), Galeria Kaufhof,
Breuninger, Autoscout24 und Manufactum haben sich in den letzten Jahren so aufgestellt. Vertikalisierung ist aber keineswegs ein Phänomen der E-Commerce-Branche: Auch Unternehmen wie die LVM-Versicherung, die Ratgeberseite gutefrage.net oder der Logistiker Kühne+Nagel bauen um. Berichten zufolge sind die Entwicklungsteams der Internet-Riesen Facebook und Amazon schon lange ähnlich organisiert.

Anzeige
Anzeige

Sind die Schnitte gut gewählt, bringt diese Art der Strukturierung einen enormen Geschwindigkeitsvorteil in der Entwicklung. Neue Features können vom betreffenden Team alleine entwickelt und live gebracht werden, da es alle nötigen Fähigkeiten mitbringt. Man spricht auch von einem Cross-Functional-Team. Personen mit unterschiedlichen Fähigkeiten wie UX-Design,
Datenmodellierung, Skalierung, Sicherheit, Produktmanagement oder tiefem fachlichem Wissen arbeiten eng zusammen und lernen voneinander.

Verschiedene Zuständigkeiten, ein ­Erscheinungsbild

Der Besucher der Website soll von dieser internen Teamstruktur jedoch nichts mitbekommen. Die größte Herausforderung im ­Zusammenhang mit Micro-Frontends ist daher die möglichst nahtlose Integration der einzelnen vertikalen Frontends untereinander. Dabei müssen jedoch Kernwerte wie technische Entkopplung und unabhängige „Deploybarkeit“ möglichst erhalten bleiben. Im Folgenden werden einige Integrationsmuster kurz umrissen.

Im einfachsten Fall kann die Integration auf Seitenebene über normale Links erfolgen. Eine solche Lösung trifft man in der E-Commerce-Welt häufig an, wenn ein Blog-System eingebunden wird. Das Blog ist aus dem Shop verlinkt. Alle Seiten, deren URL mit /blog beginnt, werden nicht vom eigentlichen Shop-System, sondern von einer eigenständigen Blog-Software ausgespielt. Aus den Blog-Artikeln wird dann wieder auf die jeweiligen Produkte im Shop verlinkt. Beide Systeme sind autark. Gibt es ein technisches Problem im Blog, läuft der Shop trotzdem unbeeindruckt weiter – und umgekehrt.

Anzeige
Anzeige

Auch im Beispiel der drei am Kaufprozess orientierten Teams „Entdecken“, „Entscheiden“ und „Bestellen“ betreibt jedes Team eine eigenständige Applikation mit eigener Datenhaltung. Dabei
sind jedem Team bestimmte Seitentypen zugeordnet: Team „Entdecken“, verantwortlich für das Auffinden des gewünschten Artikels, betreibt Homepage, Kategorie- und Suchseiten. Team „Entscheiden“ stellt dem Benutzer auf der Detailseite alle kaufrelevanten Informationen wie technische Daten, verfügbare Farben und Größen, aber auch Kundenrezensionen zur Verfügung. Team „Bestellen“ managt die Seiten des Bestellprozesses vom Warenkorb bis hin zur Bestätigungsseite und kümmert sich dabei auch um Kundenlogin und Zahlungsabwicklung. Die beschriebenen Seiten sind untereinander verlinkt. Damit es für den Benutzer nicht zu visuellen Brüchen kommt, wird meist ein gemeinsam verwendeter CSS-Styleguide, beziehungsweise eine Pattern Library,
etabliert. Dort sind neben Farbschema, Typographie und Iconsprache auch wiederverwendbare UI-Komponenten wie Buttons, Tooltipps oder die Artikel-Kacheln zu finden.

Das große Fragmente-Puzzle

Eine Integration auf Seitenebene ist jedoch nicht immer ausreichend. Auf einigen Seiten ist es erforderlich, direkt Informationen anzuzeigen, die im Verantwortungsbereich eines anderen Teams liegen. So soll beispielsweise der Header mit Navigation auf allen Seiten angezeigt werden. Team „Entdecken“, verantwortlich für das Auffinden von Artikeln, stellt dieses Element als Fragment bereit, welches von den anderen Teams inkludiert werden kann. Im Gegensatz zu den UI-Komponenten aus der Pattern Library sind Fragmente eigenständige Mini-Applikationen, welche sich auch um die Datenbeschaffung kümmern. Möchte Team „Ent­decken“ beispielsweise mit personalisierter Ausspielung von Naviga­tionspunkten experimentieren, kann es das einfach im Header-
Fragment machen, ohne sich mit den einbindenden Teams abstimmen zu müssen.

Jeder Seitentyp liegt in der Verantwortlichkeit von genau einem Team. ­Informationen und Interaktionen aus anderen Vertikalen können über ­Fragmente (Mini-Applikationen) eingebunden werden. (Grafik: Michael Geers, Icons by Freepik from flaticon.com)

Für das Inkludieren gibt es unterschiedliche technische ­Möglichkeiten. Die einfachste Lösung ist der gute alte iFrame. Hierfür muss dem einbindenden System neben der URL auch die genaue Höhe des Inhalts bekannt sein – ein Umstand, der ihn in Zeiten des Responsive Webdesigns unbrauchbar macht. Zudem verursacht der iFrame Probleme mit Accessibility, SEO und schnellem Seitenaufbau.

Anzeige
Anzeige

Eine häufig anzutreffende Lösung für die Inklusion von Fragmenten in Seiten ist auch die Integration auf Server-­Ebene. Anstelle des Headers bindet Team „Bestellen“ einfach einen ­speziellen HTML-Kommentar wie <!--#include virtual=“/entdecken-header“ --> ein, welcher dann von einem vorge­lagerten Webserver wie Nginx oder Apache durch das Markup des richtigen Headers aus Team „Entdecken“ ersetzt wird. Die hier zum Einsatz kommende Technik nennt sich Server-Side-­Includes (SSI) oder Edge-Site-Includes (ESI). Diese Standards existieren schon seit fast zwanzig Jahren und müssen im Webserver meist nur aktiviert werden. Im Gegensatz zum iFrame-Ansatz bekommt man bei dieser Lösung jedoch keinerlei Isolation für Styles und Skripte. Um ungewollte Seiteneffekte zu vermeiden, müssen sich hier vorab alle Teams auf Präfixe und Namens­konventionen, etwa für CSS-Klassen, einigen.

Um schneller auf Nutzereingaben reagieren zu können, wird das Markup inzwischen gerne direkt im Browser erzeugt und upgedated. Um Client-Side-Rendering zu unterstützen, wird eine Integration auf Browser-Ebene, sprich Javascript, benötigt. Web-Components sind seinerzeit angetreten, um ein natives Komponenten-System, ähnlich wie in React und Angular, als neutralen Web-Standard zu etablieren. Bis jetzt hat es jedoch nur ein Teilaspekt in die aktuellen Browser geschafft: Custom-­Elements. Sie bieten Entwicklern die Möglichkeit, ein eigenes HTML-­Element zu definieren und es mit Javascript-Code zu verknüpfen. Jedes Team registriert demnach ein HTML-Tag für die Fragmente, die es anderen Teams zur Verfügung stellen möchte. Das vorherige Beispiel würde dann so aussehen: <entdecken-header></entdecken-header>. Sobald der Browser ein solches Element ­findet, ruft er den entsprechenden Javascript-Code für den Header von Team „Entdecken“ auf. Dieser kümmert sich dann gegebenenfalls um das Laden von Daten und rendert seinen eigenen Inhalt in das Element. Jedes Fragment ist somit eine Mini-­Javascript-Anwendung, die mittels eines beliebigen Frameworks implementiert sein kann. Das Fragment kann über DOM-Attribute vom inkludierenden System parametrisiert werden und sich entsprechend aktualisieren <entdecken-header mode=“compact“>. Es kann aber auch andere Teile der Seite mittels nativer Browser-Events beziehungsweise Custom-Events über Neuigkeiten informieren. Custom-Elements funktionieren nur im Browser. Beim initialen Laden der Seite verhält sich das neue HTML-Tag wie ein leeres div und wird erst durch Javascript zum Leben erweckt. Um ein Flackern der Seite zu verhindern – und um wichtige ­Inhalte möglichst schnell zur Anzeige zu bringen – lässt sich der Custom-Element-Ansatz auch mit SSI für den ersten Seitenaufruf kombinieren.

Fazit

Micro-Frontends bringen eine Menge Vorteile mit sich. Die autonomen Teams können schnell agieren und auch tiefgreifende technische Änderungen auf dem „kurzen Dienstweg“ umsetzen. Durch den überschaubaren Funktionsbereich einer Vertikale steigt außerdem das Identifikationspotenzial: Jedes Team hilft dem Benutzer, eine konkrete Aufgabe erfolgreich zu erledigen. Niemand entwickelt ohne Rückbindung an Kundenbedürf­nisse. Allerdings stellt die Integration von Oberflächenfragmenten unterschiedlicher Teams hohe Anforderungen an Organisation und Architektur. Neben der nahtlosen Integration der einzelnen Frontends gehören auch das Sicherstellen einer schnellen Ladegeschwindigkeit und die Konzeption einer guten Pattern-Library zu den Herausforderungen. Diesen beiden Punkten widmet sich Teil 2 in der kommenden Ausgabe des t3n Magazin.

Mehr zu diesem Thema
Fast fertig!

Bitte klicke auf den Link in der Bestätigungsmail, um deine Anmeldung abzuschließen.

Du willst noch weitere Infos zum Newsletter? Jetzt mehr erfahren

Anzeige
Anzeige
Kommentare

Community-Richtlinien

Bitte schalte deinen Adblocker für t3n.de aus!
Hallo und herzlich willkommen bei t3n!

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team von mehr als 75 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Schon jetzt und im Namen der gesamten t3n-Crew: vielen Dank für deine Unterstützung! 🙌

Deine t3n-Crew

Anleitung zur Deaktivierung
Artikel merken

Bitte melde dich an, um diesen Artikel in deiner persönlichen Merkliste auf t3n zu speichern.

Jetzt registrieren und merken

Du hast schon einen t3n-Account? Hier anmelden

oder
Auf Mastodon teilen

Gib die URL deiner Mastodon-Instanz ein, um den Artikel zu teilen.

Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

Kommentar abgeben

Melde dich an, um Kommentare schreiben und mit anderen Leser:innen und unseren Autor:innen diskutieren zu können.

Anmelden und kommentieren

Du hast noch keinen t3n-Account? Hier registrieren

Anzeige
Anzeige