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
   

   View Slide

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
   

   View Slide

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

   View Slide

4. Was sind Micro-Frontends?
   

   View Slide

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)
   

   View Slide

6. Vertikaler Schnitt
   3-Schichten Mit Micro-Frontends
   

   View Slide

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)
   

   View Slide

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

   View Slide

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)
   

   View Slide

10. Der Weg zu Micro-Frontends im REWE Shop
    

    View Slide

11. Am Anfang war der Monolith
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide

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
    

    View Slide

16. Architektur Shop Assets & UI-Service
    

    View Slide

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

    View Slide

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
    

    View Slide

19. DUC
    Catalan
    vs.
    

    View Slide

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

    View Slide

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”
    

    View Slide

22. Ablauf eines Requests an den DUC
    

    View Slide

23. 
    …
    
    >
    >
    
    
    
    >
    >
    
    
    
    
    
    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
    

    View Slide

24. 
    
    
    
    
    
    Mobile Navigation Markup:
    
    />
    />
    
    >Some markup!
    
    
    
    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
    

    View Slide

25. Evolution des Header-Micro-Frontends
    In drei Phasen
    

    View Slide

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!
    

    View Slide

27. Architektur des Header-Service nach Phase I
    

    View Slide

28. Ausgabe des Headers nach Phase I
    Team Header
    Team Navigation
    

    View Slide

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
    

    View Slide

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!
    

    View Slide

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
    

    View Slide

32. Architektur in Phase II
    

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

36. Der Header geht in Produktion
    

    View Slide

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

    View Slide

38. Ausgabe des Such-Flyouts
    Team Search
    Team Basket
    Team Shoppinglist
    

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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
    

    View Slide

43. Bevor wir zum Schluss kommen...
    

    View Slide

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
    

    View Slide

45. Vielen Dank!
    Twitter: @drunknzombiecow
    E-Mail: nils.roehrig@rewe-digital.com
    Xing: https:/
    /www.xing.com/profile/Nils_Roehrig2
    

    View Slide