Micro-Frontends (Meetup Talk)

MicroService-Ansätze in der Frontend-Entwicklung

Meetup 30-01-2018
MicroServices Rhein Main

Transcript

1. Micro-Frontends 1 MicroService-Ansätze in der Frontend-Entwicklung
2. 2 Marco Jahn codecentric AG seit 01/2017 Consulting seit 2009 Softwareentwicklung seit 2001 Schwerpunkte UX / UI, JavaScript/TypeScript, Web Applikationen NoSQL, Neo4j Reaktive / Funktionale Softwareentwicklung 2 Über mich
3. Projekt <Projektname> Ausgangslage und Anfänge Übersicht Ein kleiner Überblick über gängige Varianten Projekt <Projektname> Status Quo und Ausblick Q & A Noch Fragen ? Kaffee Und ein netter Abend 3 AGENDA Micro-Frontends
4. 4 Betrachtung - Single SPA “Meta Framework“ - Multi SPA - Micro Apps Weitere Varianten - Multi Modul Apps - Multi Modul-Integration Varnish/SSI oder Server Side Rendering - Web Components - Erstellung einer Gesamtanwendung (Build) - “BlackBox“ Components Varianten
5. 5 Single SPA “Meta Framework“ shared shared Micro-app1 Micro-app2 Micro-app3 myapp.com - Startseite (HTML, ...) myapp.com/settings - Einstellungen (AngularJS 1.x) myapp.com/dashboard - Dashboard Ansicht (React) myapp.com/settings2 - Einstellungen (Vue.js / neu)
6. - Verwendung von mehreren Frameworks auf einer Seite - Kein „Neu Laden“ (refresh) der Seite - Jede Teilanwendung kann in einer anderen Technologie geschrieben werden - Lazy loading für optimierte initiale Ladezeit - Austausch von Applikationsteilen einfach möglich - Demo Anwendung (React, Angular 1 / 2, Vue, Ember, ...) 6 Single SPA “Meta Framework“ - ggfs. Probleme bei Major Updates eines Frameworks - Framework Eigenheiten bzgl. Ladetechnik können inkompatibel sein - Kurze Wartezeiten beim Switch von Anwendungen (neues Framework / Anwendung) - Ggfs. redundante Implementierungen in unterschiedlichen Technologien - Rahmenanwendung notwendig - Kein “Zwang“ Abhängigkeiten zu aktualisieren - Wartung der Anwendung auf vielen Frameworks - Lessons learned schwer möglich
7. 7 Multi SPA shared shared App1 Registry (shared modules) app1.domain.com shared shared App2 app2.domain.com shared shared App3 app3.domain.com Alternativ domain.com - /app1 - /app2 - /app3
8. - Jede Anwendung komplett eigenständig - Verteilung der Codebasis in Anwendung und „Shared“ - Funktioniert gut bei gleich bleibendem Technologie Stack - Einfachere Entwicklung von gemeinsamer Funktionalität - Lessons learned - Anwendungsübergreifend - Upgrade von Frameworks 8 Multi SPA - Kurze Wartezeiten beim Switch von Anwendungen (caching) - Ggfs. redundante Implementierungen in unterschiedlichen Technologien - Upgrades in Shared Modulen erzwingen eventuell Upgrades aller Anwendungen - Anwendungen auf einer Vielzahl an Frameworks muss gewartet werden (können)
9. 9 Micro Apps EventBus Shared Micro-app1 Micro-app2 Micro-app3 app1.domain.com app2.domain.com app3.domain.com
10. - Jede Anwendung komplett eigenständig - Mehrere Technologien möglich - Orchestrierung über Iframes + window.postmessage API - Portal ähnlicher Charakter - Eignet sich gut für Webseiten ähnliche Anwendungsfälle 10 Micro Apps - Man sollte die Anzahl der Technologien beschränken - Kein Lazy Loading zur Optimierung der initialen Ladezeit - Komplexität/Größe der Teilanwendungen kann beschränkt sein
11. - Multi Module Apps - Ein Modul ist eine in sich geschlossene Einheit - Jedes Modul kann in einer anderen Technologie implementiert werden - Module kommunizieren nur über einen Event Bus miteinander (Rahmen) - Sehr ähnlich zu Micro Apps, keine iFrames - Multi Module Integration Varnish/SSI oder Server Side Rendering - Zusammenbau der Anwendung erfolgt „remote“ - Alle benötigten Teile einer Anwendung (Scripts, Styles, Assets) werden im HTML zusammengeführt - Die UI Elemente werden an definierten Punkten im UI eingesetzt 11 Weitere Varianten
12. - Web Components - Man arbeitet rein auf Standards (Web Components) - Keine UI Bibliotheken wie Angular, React, ... - Erstellung einer Gesamtanwendung (Build) - Starke Kopplung zwischen Rahmenanwendung und Teilanwendungen/-Komponenten - Neue Anwendung bei Update einer Teilkomponente - “BlackBox“ Components - Jede Komponente hat ihren kompletten State - Sehr starke Kopplung zwischen Anwendungen und Komponenten 12 Weitere Varianten
13. Großprojekt zur Modernisierung der Vertriebslandschaft des Konzerns Zielplattform - Cloud Architektur - MicroServices 13 Projekt: <Projektname> Schaubild zur Verteilung nicht zugelassen
14. 14 14 Status Quo / der Anfang Sicht des Teams Status Quo / der Anfang Projektsicht (Frontend) - Kein/keine („Grüne Wiese“) - Build (für Backend vorhanden) - Vorgaben (nur Angular) - UX / UI Library bzw. Styleguide - Vorstellung was genau wir brauchen (fachl.) - „Weiche“ Vorgaben - „Wir machen MicroServices“ - Hohe Coverage/Qualtiät gewünscht - Continuous Delivery & Deployment - Deadline ~5 Monate - 2 Developers - Alles „from Scratch“ Entwickeln - UI & UX - Komponenten - Technologie Stack - Erkenntnisse - Perfekte Lösung aufgrund des Zeitplans nicht möglich - Wir werden mit Trade Offs leben - Wir versuchen uns keines der Zielszenarien zu verbauen
15. 15 Es wird mehrere (Teil-)Anwendungen geben, aber eine Zerlegung schaffen wir zeitlich nicht 1 Wir kennen kaum den Umfang / Inhalt der Teilanwendungen, welche Variante ist die Richtige ? Es gibt dringendere Probleme als eine “schöne” Zerlegung anhand der MicroServices Wir müssen uns selber in das ganze Umfeld eingewöhnen (Technik, Fachlichkeit, …) Aufgrund der Gegebenheiten entscheiden wir uns erstmal für einen Monolithen 2 3 4 15 Zielkonflikt 1 5
16. 16 Ausblick / Ziel
17. - Multi SPA Anwendung (keine Single SPA) - Interne Anwendung (Expertensystem) - Enger Kreis an Anwendern - Page Refresh ist OK - Mittels PWA/WebWorker erreichen wir eine mehr als ausreichende Ladegeschwindigkeit - Angular / Angular CLI - Update aller Abhängigkeiten spätestens alle 2-3 Sprints (1 Sprint -> 2 Wochen) - Updates i.d.R. <1-2h (auch Major Updates Angular 4.4 -> 5) - Externe Abhängigkeiten möglichst gering halten - Multi Projekt Updates später automatisieren - Architektur - MicroServices liefern auch „ihre UI“ aus - Keine Kopplung zwischen Anwendungen / Services - Leichte Erweiterbarkeit und hohe Wiederverwendbarkeit 17 Ausblick / Ziel
18. 18 Architektur – Schritt 0 (der Anfang) App1 app1.domain.com Service Service Service
19. - Verhältnis Shared <> App 1 ~ 40/60 - Geteilte Komponenten bieten - „Renderer“ Interfaces an (Bsp. Kalender Tooltip) - Callbacks/Events bei Benutzer Interaktionen - Generalisierung von UI/UX sofern möglich - Kommunikationspatterns - Parent -> Child - direkter Zugriff - Child -> Parent – Event/Listener - * -> * - Message Bus mit Nachrichtentypen 19 Architektur – Schritt 0
20. 20 Architektur – Schritt 1 ads App1 app1 Service Shared Service Service ads App2 app2 ads Blue Print
21. - Blueprint - „Core“ (Authentifizierung, Authorisierung, Error Handler, Logging, ...) - Bootstrap der Anwendung (Login, ...) - Grundlage für neue Projekte - Drop in Replacement für bereits bestehende Module - Shared - Gemeinsame Komponenten - Angular spezifische Dinge (Pipes, Service, Guards, ...) 21 Architektur – Schritt 1
22. 22 Architektur – Schritt 2 ads App1 app1 Service Shared Service Service ads App2 app2 ads Blue Print ads AppN appN
23. - Umzug von Teilen „Shared“ in den zugehörigen MicroService - Die Shared Module in den MicroServices benutzen (sofern nötig) „Shared“ - „Spezialisierung“ von Shared - Ein MicroService kapselt die ihm zugehörigen UI Elemente - Komponenten, Services, Pipes, Models 23 Architektur – Schritt 2
24. 24 Beispiel „Wegpunkt" ads App1 app1 Wegpunkt Shared Service Service ads App2 app2 ads Blue Print ads AppN appN
25. - MicroService - https://wegpunkt.cloud.domain.de /startpunkt/?filter=Frnk&limit=10&country=de - Wildcard Suche *<term>* - Angular - Komponente(n) - Service (Http + Daten) - Model - Abhängigkeiten -> Shared 25 Beispiel Wegpunkt
26. 26 Q & A
27. 27 Kaffee & einen schönen Abend
28. 28 - Microservices – Wikipedia - Frontend Services at Hello Fresh - micro-frontends.org - Single SPA - Shared EventBus - Multi SPAs that live on different URLs - Iframes using libraries and Window.postMessage API - Chrisdavies/eev - Managing Frontends in a MicroService Architecture - Including Frontend Web Components into MicroServices - ”BlackBox” React Components - Micro Frontends Quellen