BonnAgile Meetup zu Gast bei der webfactory mit "Dynamic UI Composition für µServices"

Thomas Vidic und Andreas Kluth von REWE digital hatten eine spannende Frage für den letzten Bonner Agile Tech Talk vor der Winderpause mitgebracht: wie geht man mit Frontend-Komponenten für eine Webseite um, wenn hinter der Seite bis zu 25 Entwicklerteams stehen, die möglichst autonom an Microservices arbeiten sollen?

Die Entwicklerszene ist sich grundsätzlich einig, dass eine Microservice Architektur für viele Projekte mehr Vor- als Nachteile mit sich bringt, weil sie vor allem ermöglicht, dass mehrere Entwicklungsteams unabhängig voneinander arbeiten können, ohne viel Kommunikations- und Koordinationsaufwand zu erzeugen. Tatsächlich ist eine klare Kapselung von Aufgaben im Sinne der Unix-Philosophie ("Do one thing and do it well") im Backend recht einfach möglich, weil man Funktionen wie "Nutzer kann sich mehrere Produktfotos ansehen" und "Nutzer kann ein Produkt in den Warenkorb ablegen" völlig unabhängig voneinander betrachten und umsetzen kann. Dagegen gibt es im Frontend (also "im Browser") die Herausforderung, viele dieser programmatisch deutlich unterscheidbaren Funktionen auf einer Seite gleichzeitig und nebeneinander anzuzeigen. Hier entstehen schnell viele Fragen im Hinblick auf konsistentes User Interface (UI) versus autonome Entwicklung, duplizierten Code versus geteilte und versionierte Komponenten, usw.

Thomas skizzierte in seinem Vortrag die Erfahrungen, die REWE digital in den letzten Jahren in diesem Bereich gemacht hat, und stellte drei grundlegende Herangehensweisen vor, die sie für ihre Architektur evaluiert haben:

1. Frontend-"Monolith" – ein dediziertes Frontend-Team verantwortet das gesamte User Interface und konsumiert von anderen Entwicklerteams hauptsächlich Daten über API-Endpunkte.
   Hauptvorteil: "alles aus einer Hand", damit konsistente Gestaltung und kein wild wuchernder Code
   Hauptnachteil: skaliert schlecht, ein Team wird zum Flaschenhals für alle anderen Teams
2. "Micropages" – Jede Seite wird als eigenständiger Service betrachtet und isoliert von einem zuständigen Team verwaltet und vertikal integriert, d.h. Backend und Frontend liegen im gleichen Team und eine überall verwendete Komponente wie die Navigation wird im Zweifelsfall von jedem Team neu umgesetzt.
   Hauptvorteil: Maximale Autonomie mit Null Abhgängigkeiten
   Hauptnachteil: Maximale Code-Duplikation bei großer Gefahr von visueller/funktionaler Inkonsistenz
3. "Dynamic Frontend Composition" — Kritische und komplexe Features kommen vollständig (Backend und Frontend) aus dedizierten Teams und werden von anderen Teams über Integrationsmechanismen zu ganzen Seiten zusammengestellt.
   Hauptvorteile: Kritische Features können autonom entwickelt werden und ihre visuelle/funktionale Konsistenz wird durch die Einbindung zur Laufzeit in ihrer jeweils aktuellen Version zu jedem Zeitpunkt gewährleistet
   Hauptnachteil: Teams, die übergeordnete Seiten verwalten und kritische Komponenten einbinden, verlieren ein Stück weit die Kontrolle über diese kritischen Bestandteile "ihrer" Seiten

Im Folgenden ging Thomas näher auf Details ihrer auf der "Dynamic Frontend Composition" basierenden, aktuellen Architektur ein und schilderte erste Erfolge bei ihrer kürzlichen Umstellung der "In den Warenkorb"-Komponente. Er stellte dazu den "Dynamic User Interface Composer" (DUC) vor, der ähnlich wie Zalandos tailor für die Komposition unterschiedlicher Teile einer Seite zum fertigen Endergebnis im Browser des Nutzers verantwortlich ist.

Im Anschluss an den Vortrag entwickelte sich eine spannende Diskussion mit vielen Detailfragen, so dass der zweite Teil des Abends mit etwas Verspätung erst um 21:00 Uhr weiterging. Andreas Kluth hatte sich zur Aufgabe gemacht, den von REWE digital in Node.js entwickelten (und proprietären) DUC in Java nachzubauen, um einerseits zu zeigen, dass "Java noch lange nicht tot ist" und andererseits eine Implementierung der Kernidee ihrer Software als Open-Source veröffentlichen zu können.

Andreas nahm die Zuschauer mit auf eine geführte Tour durch die Implementierung einer Demo-Produktseite und konnte zum Schluss sogar in unter 10 Minuten beispielhaft einen neuen Service ins Leben rufen, über den eine Empfehlungen-Komponente dynamisch in die Produktdetailseite integriert wurde. Chapeau!

Wir haben uns sehr über die exzellenten Vorträge und die rege Teilnahme gefreut, und hoffen, dass BonnAgile nicht zum letzten Mal bei uns zu Gast war. Vielen Dank an dieser Stelle noch einmal besonders an Andreas, der neben seinem Vortrag ganz nebenbei auch die Organisation der Meetup-Reihe mitverantwortet.