Vortrag VIII Stichpunkte

Vortrag Christian Föhlingsdorf - Challenges in the Field of Dynamic UI composition for Microservices

Herausforderungen Software zur Komposition von Microservices in einer UI

T-Shaped Developer - Entwickler soll säntliche Bereiche bearbeiten können - in der Praxis schwierig

Jedes Team soll jedoch mindestens auch Frontends bauen können

Dynamic Frontend Architektur erlaubt skalierung der Frontendentwicklung an sich

Fast jedes Backendfeature ist mit Frontendfeature verwoben, Monolith im Frontend bremst

Erste Idee: SPA - hilft nicht, nur ein Frontendrepo wieder 40 Mann im selben Team Atomic Design - Frontend in Components - On Demand vereingit - als statische Seiten ausgeliefert - nicht weil: Seiten sollten dynamisch zusammengebaut werden, weil Seiten sollen personalisiert sein, individuelle Empfehlungen

        In jeden MS eigenes Frontend -> Loadbalancer routet von Startseitenservice zu Unterservices (Links)
            keine wirkliche Entkopplung von Services, bspw. Warenkorb müsste von jedem Team implementiert werden.
            Konsistenz von Erscheinung

services do NOT share code services do NOT share databases grundsätzliche Idee (bekannt aus Backend, sollte ins Frontend übertragen werden)

Konzept: einzelne Fragments werden kombiniert (mittels Templates), jeder Service stellt seine Fragments zur Verfügung aber ein Service beschreibt das Grundkonzept der jeweiligen Seite

Komponente die Zusammenstellt: DUC DUC besteht aus emehreren Microservices

Jede Stelle auf der Seite die mit Warenkorb zu tun hat wird von Warenkorbteam betreut, daher komplette Kontrolle über domäne

DUC selbst MS Architektur - alles als API verfügbar, z. B. Route anlegen - so nah am Standard wie möglich - Nutzung von bekannten Technologien

Asset handling:

Fragements dürfen sich nicht gegenseitig beeinflussen: CSS needs to be scoped; JS must not pollute global namespace

Gateways entwickeln (DUC auch Gateway): Bringt immer möglichkeiten zentral einzugreifen ohne das jedes Team etwas tun muss (bsp. session, logging)

Fragments haben Autonomität der Teams erhöht

Viele kleine Frgmente erhöhen die Herausforderung

Tests von Fragmenten werden einfacher - Integrationstests aufgrund komplexerer Landschaft aufwändiger - DUC hilft hier aber auch

DUC unterstützt beim A/B Testen (Ähnlich Feature Toggles mit Testgruppen)

---

zu viele Entwickler in einem Repo -> Frontends aufspalten

independent Micropages -> starke Kopplung, zuviele Abhängigkeite, Konsistenzprobleme -> nicht gut

content fragments; dynamisches Inkluden (Templates/Rezepte als Basis) -> gute Lösung

Stick to HTML as much as possible

keep it simple

Routing der Anfragen durch zentralen Service, aber limitierung der Tiefe mach Sinn (performance)

Performance metric Time to first byte -> beachten

custom Sachen für performancekritische Komponenten

fragmente, streaming (übertragen der Seite bevor sie komplett fertig ist), caching, no locking, distributed parsing

passed fragments are chached (nur fragmente nicht includes, da diese dynamisch sein können); aggresive strategie

MS sind ein Invenstment und Resourcenintensiv, für größere Unternehmen sinnvoller

Kerngedanke: Skalierung von Ressourcen (Teams), nicht nur die Performance