Wie Webentwickler Komplexität reduzieren

Webapplikationen bestehen aus einem Frontend und einem Backend. Sie kommunizieren meistens mit verschiedenen Backend-Services, um an alle notwendigen Informationen zu gelangen oder entsprechende Aufträge zu platzieren. So kann es sein, dass die Produktbilder in einem Onlineshop von einem Produkte-Service kommen, die Produkteempfehlungen und Warenkorbfunktionalitäten hingegen von anderen Services.

Vor allem in grösseren Organisationen und Softwaresystemen ist es üblich, dass verschiedene Teams für die (Weiter-)Entwicklung, Bereitstellung und Wartung der Services verantwortlich sind. Dies, weil bei der Entwicklung oft Fach- respektive Domänenwissen benötigt wird.

Diese Form der Applikationsarchitektur fasst man unter dem Begriff «Microservice-orientierte Architektur» zusammen. Dabei werden die Services voneinander entkoppelt und unabhängig betrieben. Dies führt zu mehr Autonomie und Flexibilität. So ist es denkbar, dass je nach Anforderung unterschiedliche Technologien in den Services genutzt werden.

Das Problem: Back- und Frontend sind stark voneinander abhängig

Oft ist es heute so, dass das Web-Frontend von einem Team umgesetzt wird und alle Bestandteile dort zusammenlaufen. Je grösser das Frontend, desto schwieriger und komplexer ist diese Aufgabe. Änderungen und Weiterentwicklungen von Backend-Services können zwar autonom und unabhängig umgesetzt und ausgerollt werden. Je nach Änderung an einem Service braucht es jedoch auch Anpassungen am Frontend.

Das bedeutet, dass jedes Mal Anpassungen am Frontend gemacht, neu getestet und ausgerollt werden müssen. Das Frontend-Team wird dadurch zum Flaschenhals und die Backend-Teams sind abhängig davon. Dies führt zu erhöhtem Koordinationsaufwand und im schlimmsten Fall zu Wartezeiten.

Die Lösung: Grössere Flexibilität dank Microfrontends

Um dieses Problem zu lösen, ist es naheliegend, den Microservices-Architekturansatz weiterzutreiben und auf das Frontend auszuweiten. Das monolithische Frontend wird dabei in verschiedene Komponenten zerlegt, die von verschiedenen Entwicklungsteams betreut werden.

Bei diesem Architekturkonzept liefert der Backend-Service nicht nur Daten, sondern eine Mini-Applikation, welche die gesamte Funktionalität bereitstellt. Zum Beispiel liefert der Produktempfehlungs-Service eine eigene minimale Web-Applikation, die in der Frontend-Applikation eins zu eins integriert ist. Jedes sogenannte Microfrontend sorgt für eine unabhängige Persistierung, sprich hat eine eigene Datenbank oder ähnliche Speichermechanik.

Mit diesem Ansatz kann die Unabhängigkeit und Entkopplung der einzelnen Microservices komplett durch die ganze Architektur abgebildet werden. So führt jedes Entwickler-Team Entwicklung, Rollout und Themen wie Skalierung unabhängig voneinander durch. Der Koordinationsaufwand verringert sich wesentlich. Es braucht zwar weiterhin ein Frontend, in dem die einzelnen Microfrontends integriert sind, die starke Abhängigkeit entfällt jedoch.

Eine neue Herausforderung stellt sich allerdings: Microfrontends müssen miteinander interagieren. Die Übergabe von Parametern, zum Beispiel einer Produktnummer, ist notwendig, damit alle Anwendungsfälle abgedeckt sind. Hierfür gibt es verschiedene technische Ansätze, die wir in einem Folgeartikel aufzeigen.

Die Chancen von Microfrontends

•  Schnellere Time-to-Market: Die Teams sind unabhängig und flexibel, um neue Funktionen schnell und unkompliziert zu entwickeln und auszurollen – im Idealfall mit einer automatisierten CI/CD-Pipeline. Die Koordination zwischen den verschiedenen Teams und die Wartezeiten verringern sich auf ein Minimum.
• Technologische Unabhängigkeit: Jedes Team kann den für sich optimalen Technologie-Stack nutzen. Damit können Technologien ausgetauscht oder modernisiert werden, ohne dass die gesamte Applikation oder andere Bereiche davon betroffen sind.
• Entwickler-Know-how: Weil verschiedene Technologie-Stacks verwendet werden können, ist man flexibler beim Einsatz von Entwickler-Know-how. Es können zum Beispiel Technologien eingesetzt werden, bei denen die notwendigen Ressourcen vorhanden sind.
• Skalierung und Resilienz: Jedes Microfrontend wird in einer isolierten Umgebung betrieben. Verursacht ein Microfrontend Probleme (Performance, Fehler), tangiert das nur den jeweiligen Bereich und nicht die gesamte Applikation. Der Benutzer kann trotzdem mit den anderen Applikationsbestandteilen interagieren. Wenn ein Microfrontend mehr Ressourcen braucht (z. B. Speicherplatz oder CPU), ist es zudem möglich, nur dieses zu skalieren und mit mehr Ressourcen zu versorgen.
• Fehlerbehandlung: Der Umgang mit Fehlern ist sowohl ein Vor- als auch ein Nachteil von Microfrontends. Der Vorteil: Dank Microfrontends gibt es weniger Abhängigkeiten, die Fehlersuche gestaltet sich einfacher. Weil Fehler innerhalb eines einzelnen Microfrontends gesucht werden können, vereinfacht dies die Abläufe – insbesondere, wenn Microfrontends durch dedizierte Teams betreut werden.

Die Herausforderungen von Microfrontends

• Doppelspurigkeit: Das Aufsplitten der Applikationsbestandteile kann dazu führen, dass derselbe Code in verschiedenen Microfrontends zum Einsatz kommt. Codeduplikate können zu höheren Wartungskosten führen, zum Beispiel bei Anpassungen oder Korrekturen von Bugs. Dieser Nachteil kann durch den Einsatz von «shared libraries» adressiert werden. Achtung: Diese können wieder zu mehr Abhängigkeiten führen.
• Styling/UI: Microfrontends sind unabhängige Bestandteile einer Applikation. Das betrifft nicht nur die Funktionalität, sondern auch die Elemente der Benutzeroberfläche. Trotzdem soll die fertige Applikation einheitlich aussehen und das Corporate Design einhalten. Einfaches Sharing von CSS-Stylesheets oder der Einsatz eines Design-Systems, bei dem Regeln zum Generieren von Microfrontends hinterlegt sind, sind mögliche Lösungen dafür.
• Fehlerbehandlung: Bei einem Fehler kann die Eingrenzung und Fehlersuche aufwendiger sein, da verschiedene unabhängige und isolierte Microfrontends im Einsatz sind. Auch eine Code-Analyse über die gesamte Applikation ist nur mit erhöhtem Aufwand möglich.
• Grössere Komplexität: Es kann sein, dass Microfrontends miteinander kommunizieren müssen. Beispielsweise sollen sich die empfohlenen Produkte aufgrund des Hinzufügens eines Artikels in den Warenkorb aktualisieren. Es braucht also Kommunikationskanäle zwischen den Microfrontends. Hier lauert das Risiko, dass man wieder Abhängigkeiten generiert, welche die neu gewonnene Flexibilität zerstören.
• Heterogenität: Der potenzielle Einsatz von verschiedenen Technologien pro Microfrontend kann sich als Hürde erweisen, wenn ein Entwickler das Team wechselt und das notwendige Technologie-Know-how nicht vorhanden ist. Es gilt also abzuwägen zwischen mehr individueller Unabhängigkeit pro Microfrontend und übergeordneten Interessen (z. B. welche Technologie-Stacks überhaupt eingesetzt werden sollen).

Wann sind Microfrontends die richtige Wahl?

Es existieren verschiedene Möglichkeiten, eine Applikation zu strukturieren. Jede Variante hat ihre Vor- und Nachteile. Microfrontends sind – wie alles in der Softwareentwicklung – kein Allzweckmittel. Ob ihr Einsatz Sinn macht, hängt von verschiedenen Faktoren ab: von der Komplexität der Applikation, der Organisation der Entwicklerteams oder von der geforderten Agilität.

Ein Monolith kann eine adäquate Wahl sein, wenn es sich um eine simple, übersichtliche Applikation handelt oder die Applikation sauber strukturiert («geschnitten») werden kann. Wenn eine Applikation gross ist, viele Parteien involviert und allenfalls schon Microservices im Backend vorhanden sind, können Microfrontends hingegen ein Mehrwert sein.

Es empfiehlt sich deshalb, den Einsatz von Microfrontends mit einem Proof of Concept zu evaluieren und die Ergebnisse neutral zu bewerten.