Modulare Webanwendungen mit getrennten Frontend-Bereichen entwickeln

Webanwendungen wachsen meist über Jahre. Neue Funktionen kommen hinzu, mehrere Entwicklungsteams arbeiten parallel und bestehende Bereiche werden regelmäßig angepasst. Bei einem zentral aufgebauten Frontend können solche Veränderungen dazu führen, dass selbst kleinere Anpassungen umfangreiche Tests und gemeinsame Veröffentlichungen erfordern.

Eine modulare Frontend-Architektur verfolgt einen anderen Ansatz. Die Benutzeroberfläche wird in abgegrenzte Bereiche zerlegt, die technisch getrennt entwickelt und veröffentlicht werden können. Für die Nutzung erscheint dennoch eine zusammenhängende Anwendung. Entscheidend ist deshalb nicht allein die Aufteilung des Programmcodes, sondern auch das Zusammenspiel der einzelnen Module.

Technische Aufteilung statt zentralem Frontend

Bei nicht-modularen Webanwendungen, sogenannten Frontend-Monolithen, befinden sich große Teile einer Benutzeroberfläche innerhalb einer gemeinsamen Codebasis. Änderungen an einer Komponente können deshalb Auswirkungen auf andere Bereiche haben. Vor einer Veröffentlichung sind entsprechende Abhängigkeiten zu prüfen. Arbeiten mehrere Teams am selben Frontend, müssen Entwicklungsstände und Releases aufeinander abgestimmt werden.

Bei der Softwaremodularisierung werden umfangreiche Softwaresysteme in kleinere, voneinander abgegrenzte Module zerlegt. Auf Frontends übertragen bedeutet das beispielsweise, einen Produktkatalog, den Warenkorb und die Benutzerverwaltung als getrennte Bereiche zu entwickeln.

Ein Micro-Frontend bildet einen solchen abgegrenzten Teil der Benutzeroberfläche. Ein Entwicklungsteam kann für diesen Bereich den Code erstellen, Tests durchführen und neue Versionen veröffentlichen. Andere Module bleiben davon zunächst unberührt. Die fachliche Abgrenzung sollte so gewählt werden, dass nicht zahlreiche gegenseitige Abhängigkeiten zwischen den Modulen entstehen.

App-Shell verbindet getrennte Bereiche

Getrennte Frontend-Module müssen für die Nutzung wieder zu einer gemeinsamen Anwendung zusammengesetzt werden. Frameworks wie Piral verwenden dafür eine sogenannte App-Shell. Sie bildet den übergeordneten Rahmen, in den einzelne Module eingebunden werden.

Die App-Shell kann zentrale Aufgaben wie Navigation, Routing oder gemeinsam genutzte Funktionen übernehmen. Routing bezeichnet die Zuordnung einer aufgerufenen Adresse zu einem bestimmten Bereich der Webanwendung. Ein Produktmodul kann beispielsweise unter einer anderen Route erreichbar sein als die Benutzerverwaltung, obwohl beide innerhalb derselben Oberfläche erscheinen.

Auch die technische Einbindung unterschiedlicher Frameworks ist möglich. Ein bestehender Bereich muss daher nicht allein deshalb neu entwickelt werden, weil ein anderes Team für ein neues Modul eine andere technische Basis verwendet. Ob mehrere Frameworks innerhalb einer Anwendung zweckmäßig sind, hängt jedoch von den technischen Anforderungen und den vereinbarten Entwicklungsvorgaben ab.

Abhängigkeiten zwischen Modulen begrenzen

Die Trennung des Programmcodes allein reicht nicht aus. Frontend-Module tauschen teilweise Daten aus oder greifen auf gemeinsame Backend-Dienste zu. Solche Verbindungen benötigen definierte Schnittstellen. Andernfalls verlagern sich Abhängigkeiten lediglich vom gemeinsamen Quellcode auf die Verbindungen zwischen den Modulen.

Wenige klar definierte Schnittstellen erleichtern die technische Abgrenzung der Module. Das Prinzip der Schnittstellenminimalität zielt darauf ab, die notwendigen Verbindungen und übertragenen Parameter zwischen Modulen zu begrenzen.

Gemeinsame Gestaltungsregeln sind ebenfalls erforderlich. Schriftarten, Abstände, Bedienelemente und Navigationsmuster sollten nicht von Modul zu Modul wechseln. Technisch getrennte Bereiche dürfen für die Nutzung nicht wie voneinander unabhängige Webseiten erscheinen.

Migration bestehender Anwendungen in Etappen

Eine bestehende Webanwendung muss für die Einführung einer modularen Architektur nicht vollständig ersetzt werden. Einzelne Bereiche können nacheinander aus einem Frontend-Monolithen herausgelöst werden. Für den ersten Migrationsschritt eignet sich beispielsweise ein fachlich weitgehend abgegrenzter Bereich mit wenigen Abhängigkeiten zu anderen Komponenten.

Vor der Trennung ist zu untersuchen, welche Daten der ausgewählte Bereich benötigt, welche gemeinsamen Komponenten bestehen bleiben sollen und welche APIs verwendet werden. API steht für „Application Programming Interface“ und bezeichnet eine Programmierschnittstelle, über die Softwaresysteme Daten oder Funktionen austauschen.

Nach der technischen Abgrenzung kann das neue Modul getrennt getestet und veröffentlicht werden. Weitere Bereiche lassen sich später nach demselben Grundprinzip aus dem bisherigen Frontend herauslösen. Eine schrittweise Migration begrenzt den Umfang gleichzeitig vorgenommener Änderungen und lässt bestehende Komponenten zunächst weiterlaufen.

Getrennte Releases benötigen gemeinsame Regeln

Verschiedene Module verändern auch den Veröffentlichungsprozess. Ein Team kann eine neue Version seines Bereichs bereitstellen, ohne auf einen gemeinsamen Release-Termin aller Frontend-Teams warten zu müssen. Voraussetzung dafür sind festgelegte Regeln für Versionen und technische Abhängigkeiten.

Piral Cloud ergänzt die App-Shell um Funktionen zur Verwaltung verteilter Module und ihrer Releases. Bei mehreren Teams lässt sich darüber nachvollziehen, welche Modulversion innerhalb einer Anwendung eingesetzt wird und welche Abhängigkeiten bestehen.

Technische Governance bezeichnet in diesem Zusammenhang verbindliche Vorgaben für Entwicklung und Betrieb. Dazu können Regeln für Schnittstellen, Versionierung, Tests, gemeinsame Komponenten und Veröffentlichungen gehören. Fehlen solche Vereinbarungen, kann eine stark aufgeteilte Anwendung mit zunehmender Zahl von Modulen schwerer zu überblicken sein.

Wann eine modulare Frontend-Architektur geeignet ist

Nicht jede Webanwendung benötigt eine Aufteilung in verschiedene Frontend-Module. Bei kleinen Projekten mit einem einzigen Entwicklungsteam kann der zusätzliche Aufwand für App-Shell, getrennte Deployments und Schnittstellen unverhältnismäßig sein.

Anders sieht es bei größeren Plattformen aus, bei denen mehrere Teams für unterschiedliche Funktionsbereiche verantwortlich sind. Dort können eigenständige Module verhindern, dass jede Änderung einen gemeinsamen Frontend-Release voraussetzt. Maßgeblich sind daher weniger einzelne Technologien als die Größe der Anwendung, vorhandene Abhängigkeiten und die Verteilung der Entwicklungsaufgaben.

Fazit

Modulare Frontends teilen umfangreiche Benutzeroberflächen in technisch abgegrenzte Bereiche. Die Trennung betrifft Entwicklung, Tests, Versionierung und Veröffentlichungen, während für die Nutzung weiterhin eine gemeinsame Oberfläche bestehen kann.

Der technische Nutzen hängt wesentlich von der Abgrenzung der Module und den Schnittstellen zwischen ihnen ab. App-Shells wie bei dem Open-Source Framework Piral übernehmen die Zusammenführung der Bereiche. Gemeinsame Vorgaben für Navigation, Gestaltung, Tests und Versionierung bleiben dennoch erforderlich. Bei umfangreichen Plattformen mit mehreren Entwicklungsteams kann dieses modulare Architekturprinzip die getrennte Bearbeitung einzelner Frontend-Bereiche erleichtern.