Zusammenfassung Vortrag: Wolf Schlegel & Niko Hellwig - Archi-Lab/fae-team-1 GitHub Wiki
Warum Micro frontends?
- Monolithen sind nicht gut skalierbar
- Monolithen skalieren nicht gut technisch
- Bei einem Monolithen arbeitet man in großen Teams (mühsam)
- Mangelnde technische Wartbarkeit und Erweiterbarkeit
Headless or Headfull microservices?
Headless Microservices
- Man hat drei Services (A,B,C)
- Jeder für sich hat eine Domäne
- Oben drüber hat man eine UI (Es gibt eine Big UI monolithen)
- Das UI geht über alle Services hinweg
- Es gibt eine UI für alle Services (UI wird von einem Team gebaut)
Big UI monolith
- Alle Microservices teilen sich eine UI
Little frontends
- Abhängigkeiten zwischen wenigen Teams (z.B. 2-3)
- Nutzen, wenn man der Meinung ist, dass sich die kleinen Teams abstimmen können ohne dabei sich im weg zu stehen (z.B. A macht nicht B langsamer)
Headfull Microservices
- Innerhalb der MS A, B und C gibt es jeweils Anteile der Benutzerinteraktion (UI A, UI B und UI C)
- Ganz oben liegt eine technische Schicht, die das ganze zusammenführt
- Damit man alles aus einem Guss sehen kann
Decomposed UI
- Jeder Microservice hat eine eigene UI
Shared UI
- Wiederverwendung von Komponenten
- Einzelne Teile der UI werden wiederverwendet (Bsp.: Warenkorb Widget)
Unterschiede der beiden Varianten Headless und Headfull
- 2 Unterschiede:
- Wie viele Teams mitspielen
- Technologien, die benutzt werden
Headless Microservice
- Gibt es vier Teams (Team A, B, C und UI)
- Hier entsteht ein Flaschenhals Effekt
- Hier muss man nachdenken, in welcher Reihenfolge man Dinge entwickelt (z.B. Product Owner kommen von den Teams an und sagen xy soll umgesetzt werden)
- Zeitpunkt, der Markteinführung der Funktionalität kann dadurch beeinflusst werden
Headfull Microservice
- Gibt es drei Teams (Team A, B und C)
- Hier kann man autonom arbeiten
- Weniger Teams, weniger Abhängigkeiten
Es gibt bei beiden Abhängigkeiten, die man nicht lösen kann --> Man kann zwischen zwei unterschiedlichen Abhängigkeiten wählen
- Beim Frontend Monolithen gibt es Abhängigkeiten zwischen Teams
- Teams müssen ggf. aufeinander warten, um Dinge an den Markt zu bringen
- Bei den Micro Frontends gibt es Abhängigkeiten im Hinblick auf die Technolgieauswahl
Man muss sich die Frage bei der Auswahl der Abhängigkeiten stellen, ob man eine bessere User Experience haben möchte oder schneller am Markt sein möchte?
- Frontend Monolithen: Dieses Modell macht es einfacher, eine perfekte User Experience zu bauen --> Man hat ein Team
- Nachteil: Man kommt später mit den neun Features auf den Markt
- Beim Micro Frontend gilt der Gegensatz (Man kommt schnell auf den Markt mit den neuen Features aber hat nicht eine perfekte User Experience)
Auswahl treffen, ob man MS mit oder ohne Köpfen haben möchte
- Für die Entscheidung ist es wichtig, sich auf das Interesse des Unternehmens zu beziehen --> Man muss sich die Frage stellen, was für das Unternehmen wichtig ist und nicht für einen selbst
APIs über Backends for frontends (BFFs)
- Backend for frontends
- Spezifische APIs
- Bedürfnisse eines Geräts/Mediums werden abgebildet
- Bsp: Webseitenöffnung auf einem Mobilen Gerät oder auf einem Rechner
- Frontend für jedes unterschiedliche Medium wird i.d.R. anders aussehen
- Self-contained systems
- Autonome Webapplikationen
- Service API bildet die Domäne ab --> Service APIs sind verpflichtend/notwendig und BFF sind optional
Implementierung von Micro frontends
- Es gibt verschiedene Möglichkeiten ein Micro frontend aufzubauen
Integration
- Ist von Bedeutung, wenn die Micro frontends miteinander kommunizieren wollen z.B. um Daten zu teilen (dafür gibt es auch verschiedene Möglichkeiten, siehe unten)
- Frontend only: Im Frontent können sich verschiedene Komponenten miteinander unterhalten
Drei verschiedene Methoden zur Kommunikation zwischen Frontend und Backend Microservices
Jeder der Methoden hat Vor- und Nachteile, die abgewägt werden müssen. Entscheidung der Nutzung fällt individuell aus
- Frontend to Backends
- Mehr Daten
- Backend direct
- Wenn man nur mit den eigenen MS kommunizieren möchte
- Weniger Daten
- Backend BFF
- Hier darf keine Business Logik vorhanden sein
- Dient zur Zusammenführung und Aufführung von Daten
Sonstiges
Bei Microservices Architekturen, stellt die Durchführung von Ende zu Ende Test ein zentrales Problem dar. Hierzu konnten keine effektiven Lösung gefunden werden. Aufgrund dessen werden diese Tests sehr oft einfach nicht beachtet bzw. ausgeführt.
Bei MS spielen autonome Teams eine wichtige Rolle --> können unabhängig voneinander Arbeiten.