Integrations-Patterns bei JavaScript-Anwendungen

Webanwendungen werden heutzutage üblicherweise als Single-Page-Anwendung gebaut, um das bestmögliche Verhalten hinsichtlich UI und UX zu erhalten. Gerade bei größeren Anwendungen kann es sinnvoll sein, die Anwendung in kleinere Teile aufzuspalten.

Architektur/Methoden  –  8 Kommentare
Integrations-Patterns bei JavaScript-Anwendungen

Es gibt mehrere Varianten, wie Micro-Frontends entwickelt werden können, die unterschiedliche Kompromisse hinsichtlich Entwicklungsprozess oder UI/UX eingehen. Denn dem Aufteilen der Anwendung in mehrere Teile steht der Wunsch des Benutzers gegenüber, dass sich die UI einheitlich und konsistent verhalten soll.

Frontend-Architektur unterscheidet sich in einem wesentlichen Punkt von der des Backends: Der Benutzer und sein Erlebnis beim Benutzen der UI sind Teil des Aufgabenfelds. Für den Benutzer einer Anwendung sind häufig ganz andere Dinge wichtig als für die Entwickler der Anwendung. Aber je nach Anwendungsfall sind die Anforderungen der Benutzer ebenso wichtig, wenn nicht noch wichtiger.

Anwender möchten eine stimmige Darstellung der Anwendung (Abb. 1)

Jeder Nutzer einer Webanwendung wünscht sich zumindest eine schnelle, konsistente und stimmige Darstellung der Daten. Wen verwirrt oder gar ärgert nicht die Anzeige, dass noch zehn Nachrichten ungelesen sind, obwohl man gerade alle durchgesehen hat. Das klingt wie eine Kleinigkeit, aber eine solche inkonsistente Darstellung kostet Effizienz bei der Nutzung. Dazu verliert man zunehmend an Lust, eine solche Anwendung zu nutzen. Wenn man leicht auf eine Alternative ohne einen solchen Fehler wechseln kann, wird man das vielleicht tun. Die UI kann sowohl Wettbewerbsvorteil als auch -nachteil sein.

Meist wünschen sich Nutzer auch unmittelbare Reaktionen auf Eingaben oder andere Interaktionen. Wenn jemand etwas Ungültiges in ein Formularfeld einträgt, möchte man das nicht erst beim Abschicken des kompletten Formulars, sondern direkt bei der Eingabe oder unmittelbar nach Verlassen des Felds wissen.

Da Roundtrips über einen Server nach jeder Interaktion zu lange dauern würden, muss dazu die Logik für die Validierung im Browser liegen. Und damit sich eine Eingabe überhaupt validieren lässt, müssen auch die erforderlichen Daten im Browser liegen. Das ermöglicht dann auch Bedienkonzepte die von Desktop-Anwendungen bekannt sind, etwa Drag'n'Drop oder interaktive Darstellungen von Grafiken und Diagrammen.

Die dazu passende Architektur ist die sogenannte Single Page Application (SPA). Sie bringt sowohl die Logik als auch die Daten in den Browser. Der Server kann entweder ganz wegfallen, nur noch als Lieferant für Daten dienen oder weiterhin die Business-Logik enthalten. Clientseitig werden SPAs in JavaScript üblicherweise mit Frameworks wie Angular oder React umgesetzt.

Architekturdiagramm einer SPA (Abb. 2)

Fast könnte der Artikel hier zu Ende sein: Wenn man eine erstklassige UI/UX im Web braucht, die mit dem gewohnten Komfort und Prinzipien von Desktopanwendungen mithalten kann, gibt es zu einer Single Page Application keine Alternative. Das folgt aus den obigen prinzipiellen Überlegungen. Ob die Story hier zu Ende ist, hängt allerdings von der Größe der Anwendung ab und ob man diese noch mit einem einzigen Team entwickeln kann oder möchte. Denn nicht nur Anwender sind Stakeholder in der Anwendungsentwicklung, sondern auch die Entwickler und die Organisation, in der sie sich befinden.

Entwicklerteam als Stakeholder (Abb. 3)

Wer zur Entscheidung kommt, die Anwendung nicht in einem Team, sondern in mehreren zu entwickeln, zieht die Konsequenz daraus, die Anwendung in Module aufzuteilen. Jedes Modul lässt sich dann mehr oder minder autark von einem eigenen Team entwickeln. Daraus resultiert aber eine neue Herausforderung: Wenn man für die Entwicklung mit mehreren Teams die Anwendung in Module zerteilt und somit entkoppelt, muss man sie für die konsistente UI wieder koppeln. Wie im Folgenden zu sehen, geht das leider nicht ohne Kompromisse. Man muss sich entscheiden, ob man eher beim Nutzererlebnis (UI/UX) oder beim Entwicklungsprozess Abstriche in Kauf nehmen will.