Micro-Frontends im REWE Shop - Evolution eines Headers

Man stelle sich vor, dass cross-funktionale Entwicklungsteams in ihrer Arbeit vollständig unabhängig voneinander sind und Features von Ende zu Ende verantworten. Dabei ist jedes Team immer releasefähig, ohne auf andere Teams Rücksicht nehmen zu müssen. Trotzdem soll am Ende für den Nutzer eine konsistente und bereichernde Erfahrung "wie aus einem Guss" möglich sein.

Schnell stellt sich folgende Frage: Geht das überhaupt?

Im REWE Shop wurde der Versuch gewagt, diese Frage zu beantworten. Dieser Vortrag stellt einen Erfahrungsbericht des Entwicklungsprozesses von einem monolithischen Frontend zu einer Lösung auf Basis von Micro-Frontends anhand des Website-Headers vor. Dabei wird nicht nur geklärt, was dieser Begriff überhaupt bedeutet. Sondern insbesondere auch, wie er im REWE Shop angewendet wird, wie erfolgreich das ist und was wir daraus gelernt haben.

Transcript

1. Micro-Frontends im REWE Shop Evolution eines Headers
2. 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: nils.roehrig@rewe-digital.com Xing: https:/ /www.xing.com/profile/Nils_Roehrig2 Software Engineer E-Commerce Plattform
3. Stellt euch vor... • Unabhängige, cross-funktionale Teams • Immer releasefähig • Deployments ohne Rücksichtnahme • Positive Erfahrung für den Nutzer • Geht das?
4. Was sind Micro-Frontends?
5. 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)
6. Vertikaler Schnitt 3-Schichten Mit Micro-Frontends
7. 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)
8. Illustration des Prinzips Such-Fragment Login-Fragment Markt-Fragment Einkaufslisten-Fragment Warenkorb-Fragment Produktkachel-Fragmente Navigations-Fragment
9. 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)
10. Der Weg zu Micro-Frontends im REWE Shop
11. Am Anfang war der Monolith
12. 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
13. 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
14. “Was können wir tun um das zu beheben?” — REWE digital Entwickler
15. 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
16. Architektur Shop Assets & UI-Service
17. “Ist das jetzt ein Micro-Frontend?” — das Publikum
18. 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
19. DUC Catalan vs.
20. Catalan • Eigenentwicklung der REWE digital • UI-Service-Konzept für jeden Service • Zunächst der Favorit • Gescheitert an Entwicklerakzeptanz
21. DUC • Eigenentwicklung der REWE digital • Ansammlung mehrerer Microservices • Composing von UI-Fragmenten • Weitere Aufgaben ◦ A/B-Testgruppen ◦ Routing ◦ Session-Handling ◦ uvm. “Dynamic UI Composition”
22. Ablauf eines Requests an den DUC
23. <html> <head> … </head> <body> <div class="ths-mobile-navigation__item ths-mobile-navigation__item--shoppinglist" > <meso-include src="http://shoppinglist-service/views/shoppinglist-button?type=mobile" > <!-- Fallback goes here --> </meso-include> </div> <div class="ths-mobile-navigation__item ths-mobile-navigation__item--basket" > <meso-include src="http://basket-service/basketLink/{{ basket-id }}" > <!-- Fallback goes here --> </meso-include> </div> </body> </html> 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
24. <html> <head> <script src="https://duc-base/static/base/react.js" /> <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
25. Evolution des Header-Micro-Frontends In drei Phasen
26. 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!
27. Architektur des Header-Service nach Phase I
28. Ausgabe des Headers nach Phase I Team Header Team Navigation
29. 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
30. 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!
31. 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
32. Architektur in Phase II
33. Ausgabe des Headers nach Phase II Team Shoppinglist Team Basket Team Header Team Navigation
34. 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
35. 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
36. Der Header geht in Produktion
37. Phase III • Widerstand geht zurück • Betrieb sehr ruhig • Neue Includes werden behutsam eingeführt • Neuer Testing Guide entsteht Der Staub legt sich
38. Ausgabe des Such-Flyouts Team Search Team Basket Team Shoppinglist
39. We’ve come a long way Aber was hat uns das gebracht?
40. 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
41. Kernideen Revisited 1. Technologische Unabhängigkeit 2. Isolierter Code 3. Team-Prefixe 4. Native Browser Features 5. Robuste Applikationen
42. 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
43. Bevor wir zum Schluss kommen...
44. 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
45. Vielen Dank! Twitter: @drunknzombiecow E-Mail: nils.roehrig@rewe-digital.com Xing: https:/ /www.xing.com/profile/Nils_Roehrig2