Micro-Frontends im REWE Shop Evolution eines Headers 

Nils Röhrig Seit 2016 bei REWE digital Frontend-Entwicklung Verantwortungsbereiche: Website-Header, Markt- und Service-Auswahl, Registrierung für Kaufmannslieferservice Twitter: @drunknzombiecow E-Mail: [email protected] Xing: https:/ /www.xing.com/profile/Nils_Roehrig2 Software Engineer E-Commerce Plattform 

Stellt euch vor... ● Unabhängige, cross-funktionale Teams ● Immer releasefähig ● Deployments ohne Rücksichtnahme ● Positive Erfahrung für den Nutzer ● Geht das? 

Was sind Micro-Frontends? 

Conway’s law “Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.” — M. Conway [1] [1]: http:/ /www.melconway.com/research/committees.html (Abgerufen am 14.05.2018) 

Vertikaler Schnitt 3-Schichten Mit Micro-Frontends 

Micro-Frontends Begriff auf dem Thoughtworks Technology Radar [2] Seit November 2016 ● Erweiterung des Microservice-Gedanken auf das Frontend ● Komposition von UI-Fragmenten ● Teams verantworten Features von Ende zu Ende ● Entwicklung, Test und Deployment sind unabhängig von anderen Features ● Vermeidung von Frontend-Monolithen [2]: https:/ /www.thoughtworks.com/de/radar/techniques/micro-frontends (Abgerufen am 14.05.2018) 

Illustration des Prinzips Such-Fragment Login-Fragment Markt-Fragment Einkaufslisten-Fragment Warenkorb-Fragment Produktkachel-Fragmente Navigations-Fragment 

Allgemeine Punkte Wir kommen am Ende nochmal darauf zurück und vergleichen diese Punkte mit der Umsetzung im REWE Shop Kernideen hinter Micro-Frontends Nach micro-frontends.org [3] 1. Technologische Unabhängigkeit: Teams wählen und upgraden ihren Stack unabhängig voneinander 2. Isolierter Code: Der Quellcode der einzelnen Teams ist voneinander isoliert 3. Team-Prefixe: Falls eine echte Isolation nicht möglich ist, sollte mit Prefixes gescoped werden 4. Native Browser Features: Browser APIs wie z.B. CustomEvent sind einer eigenen Lösung vorzuziehen 5. Robuste Applikationen: Nützlichkeit zum Beispiel durch Universal Rendering und Progressive Enhancement [3]: https:/ /micro-frontends.org/ (Abgerufen am 14.05.2018) 

Der Weg zu Micro-Frontends im REWE Shop 

Am Anfang war der Monolith 

Der erste REWE Shop ● Übernahme durch REWE digital im Jahr 2014 ● Monolithische MVC Applikation ○ Apache Struts ○ JSP-Templates ○ Statische Assets Da ist der Header ● Header ein kleiner Teil dieses Gesamtprodukts 

Probleme Skalierung: ● Starkes Wachstum ● 40+ Entwickler, Tendenz steigend ● Tendenziell hoher Ressourcenbedarf Build- und Testprozess: ● Dauer: ~4 Stunden ● Bei jedem Fix oder Feature fällig Releases: ● Mit Glück einmal im Monat ● Keine unabhängigen Features ● Bug- und Security-Fixes dauern 

“Was können wir tun um das zu beheben?” — REWE digital Entwickler 

Shop Assets & UI-Service ● UI-Service als Aggregation Layer ○ Proxy ○ Konsumiert REST ○ Komponiert Header ● Shop Assets ○ Templates, Styles, Scripts ○ Entwicklung gegen Mocks ○ Deployment in CDN Da ist der Header 

Architektur Shop Assets & UI-Service 

“Ist das jetzt ein Micro-Frontend?” — das Publikum 

Bewertung Shop Assets & UI-Service Pros 1. Header als eigener Service: Das Header-Frontend kann bei diesem Ansatz unabhängig entwickelt werden 2. Fachliche Teams: Datenhaltung und Business-Logik der Fachlichkeiten liegen in den Teams 3. Nutzung CDN: Durch die Nutzung eines CDNs können statische Inhalte besser verteilt werden Contras 1. Header bündelt sehr viele Shop-Funktionen: Das bedeutet, es gibt ein großes Repo an dem Entwickler vieler Teams arbeiten 2. Tech-Stack Lock-in: Der Tech-Stack für das Frontend ist architekturbedingt dauerhaft festgelegt 3. Frontend-Monolith: Das Frontend ist weiterhin monolithisch aufgestellt, mit allen Nachteilen 

DUC Catalan vs. 

Catalan ● Eigenentwicklung der REWE digital ● UI-Service-Konzept für jeden Service ● Zunächst der Favorit ● Gescheitert an Entwicklerakzeptanz 

DUC ● Eigenentwicklung der REWE digital ● Ansammlung mehrerer Microservices ● Composing von UI-Fragmenten ● Weitere Aufgaben ○ A/B-Testgruppen ○ Routing ○ Session-Handling ○ uvm. “Dynamic UI Composition” 

Ablauf eines Requests an den DUC 

… Fallback-Markup Andere Micro-Frontends inkludieren “Meso-Includes” in action Substitution von Session-Headern URL zum inkludierten UI-Endpunkt Seiten-Template Der Tagname “meso-include” basiert auf “mesozoices”, dem Namen der Kompositionsbibliothek des DUCs 

<link type="text/css" src="https://duc-base/static/base/fonts.min.css" /> </head> <body> <h2>Mobile Navigation Markup:</h2> <meso-content> <link rel="stylesheet" src="https://shop.rewe-static.de/navigation-service/main.jdf8734.min.css" /> <script src="https://img.rewe-static.de/navigation-service/main.27gdh34.min.js" /> <div class="ths-mobile-navigation__react-app-root" /> <div class="ths-mobile-navigation__info-text" >Some markup!</div> </meso-content> </body> </html> Ein Micro-Frontend bereitstellen “Meso-Contents” in action Minifiziertes JS & CSS vom CDN DUC Base Includes für lokale Entwicklung Alles außerhalb von meso-content wird ignoriert GET /navigation-service/ui/mobile-menu Returns text/html 

Evolution des Header-Micro-Frontends In drei Phasen 

Phase I ● Neuer Microservice ○ DUC-konform ○ Micro-Frontend ● Code Reuse ○ Shop Assets ○ UI-Service ● Zeitdruck: ~6 Wochen ● Nahezu keine Includes Let’s get this party started! 

Architektur des Header-Service nach Phase I 

Ausgabe des Headers nach Phase I Team Header Team Navigation 

Erkenntnisse in Phase I Scoping ● Hohe CSS-Spezifität problematisch ● CSS-Regeln der Micro-Frontends können interferieren ● Konflikte zwischen JS-Komponenten Umfang ● Viele unterschiedliche Funktionen ● Fachlichkeiten anderer Teams Testbarkeit ● Zukünftig potenziell problematisch 

Toll, unser Release-Termin hat sich verschoben. Sollen wir jetzt einfach still sitzen und warten? Auf gar keinen Fall! Wir bauen jetzt einfach alle anderen Includes auf einmal ein! Klasse Idee! Dabei kann ja gar nichts schiefgehen! 

Phase II ● “Verzögerungen im Betriebsablauf” ○ Erste Iteration noch nicht erprobt ● Viele neue Includes ○ Hoher Integrationsaufwand ● Fachlichkeiten reduzieren ○ Warenkorb ○ Einkaufsliste ● Widerstand im Team ○ “Neue Architektur” gefällt nicht jedem Include-Hell on Earth 

Architektur in Phase II 

Ausgabe des Headers nach Phase II Team Shoppinglist Team Basket Team Header Team Navigation 

Erkenntnisse in Phase II Eins nach dem Anderen ● Nicht zuviel auf einmal integrieren ● Verzögerungen durch zu viele Baustellen Testing ist hart ● Integration erst zur Laufzeit ● Lauffähigkeit nach jedem Deployment sicherstellen? Hoher Kommunikationsaufwand ● Viele Includes, teils verschachtelt ● Viele Teams involviert ● Jedes einzelne kann Probleme für die Gesamtapplikation bringen 

Probleme mit der Testbarkeit ● Vollständig in Team-Verantwortung ● Lokale Entwicklung und Integration kaum möglich ● Deployments in Staging-Umgebung oft erforderlich ● Wie stellt man die Funktionsfähigkeit der Gesamtapplikation sicher? Konsequenzen aus der Fragmentierung 

Der Header geht in Produktion 

Phase III ● Widerstand geht zurück ● Betrieb sehr ruhig ● Neue Includes werden behutsam eingeführt ● Neuer Testing Guide entsteht Der Staub legt sich 

Ausgabe des Such-Flyouts Team Search Team Basket Team Shoppinglist 

We’ve come a long way Aber was hat uns das gebracht? 

Ergebnisse der Evolution Pros 1. Vertikaler Schnitt: Fachlichkeiten sind vollständig in den Teams die sie verantworten 2. Unabhängigkeit: Alle Teams können in großem Maße unabhängig releasen; kein Monolith mehr 3. Release-Geschwindigkeit: Neue Features, Bug-, Security-Fixes sehr schnell von Idee bis Produktion ausgerollt 4. Freie Werkzeugwahl: Jedes Team kann seinen kompletten Tech-Stack selber wählen Contras 1. Kommunikationsaufwand: Absprachen mit anderen Teams sind herausfordernd 2. Konsistenz im User Interface: Entweder man lässt Inkonsistenzen zu oder man schafft Abhängigkeiten 3. Testbarkeit: Vollständige Systemtests schwierig. Teams müssen Integration sicherstellen. 4. Verantwortung für ganzheitliche Themen: Durch die strikte vertikale Trennung fehlen klare Verantwortliche für z.B. Performance 

Kernideen Revisited 1. Technologische Unabhängigkeit 2. Isolierter Code 3. Team-Prefixe 4. Native Browser Features 5. Robuste Applikationen 

Die drei wichtigsten Dinge Kommunikation Die Entwickler in allen beteiligten Teams müssen vor und während der initialen Entwicklung im regen Austausch stehen. Später reichen meist auch kurze Absprachen. Isolation Der Code der Micro-Frontends aller beteiligten Teams muss vollständig isoliert sein. Verantwortung Die Entwickler in den Teams müssen bereit sein, die vollständige Verantwortung für ihre Micro-Frontends zu übernehmen. Von der Planung bis zum Betrieb. Wenn ihr diesen Weg in Betracht zieht 

Bevor wir zum Schluss kommen... 

Open Source Optionen ● DUC wird zukünftig Open Source ○ https:/ /github.com/rewe-digital-incubator im Auge behalten ● Partielle Reimplementierung in Java ○ https:/ /github.com/rewe-digital/integration-patterns 

Vielen Dank! Twitter: @drunknzombiecow E-Mail: [email protected] Xing: https:/ /www.xing.com/profile/Nils_Roehrig2