Pro Yearly is on sale from $80 to $50! »

Micro-Frontends im REWE Shop - Evolution eines Headers

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.

11b1fcba854581c0d80ba3c22f81c5d5?s=128

Nils Röhrig

March 11, 2019
Tweet

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