Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

Micro-Frontends im REWE Shop - Evolution eines ...

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.

Nils Röhrig

March 11, 2019
Tweet

Other Decks in Programming

Transcript

  1. 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
  2. Stellt euch vor... • Unabhängige, cross-funktionale Teams • Immer releasefähig

    • Deployments ohne Rücksichtnahme • Positive Erfahrung für den Nutzer • Geht das?
  3. 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)
  4. 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)
  5. 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)
  6. 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
  7. 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
  8. 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
  9. 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
  10. Catalan • Eigenentwicklung der REWE digital • UI-Service-Konzept für jeden

    Service • Zunächst der Favorit • Gescheitert an Entwicklerakzeptanz
  11. DUC • Eigenentwicklung der REWE digital • Ansammlung mehrerer Microservices

    • Composing von UI-Fragmenten • Weitere Aufgaben ◦ A/B-Testgruppen ◦ Routing ◦ Session-Handling ◦ uvm. “Dynamic UI Composition”
  12. <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
  13. <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
  14. 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!
  15. 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
  16. 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!
  17. 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
  18. 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
  19. 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
  20. Phase III • Widerstand geht zurück • Betrieb sehr ruhig

    • Neue Includes werden behutsam eingeführt • Neuer Testing Guide entsteht Der Staub legt sich
  21. 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
  22. 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
  23. 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