Micro Frontends over UI Monoliths (Wolf Schlegel und Niko Hellwig)

**TODO: **

• Nochmal inhaltlich reviewen
• **Kann man die eingebundenen Grafiken ggf. rausnehmen? **
• Kann man die Tradeoffs irgendwo schön noch erklären? (wie wichtig ist UX in dem projekt vs Skalierbarkeit und damit zusammenhängende Architekturkonsequenzen, etc. )
• **Kommunikationsmethoden sollten etwas mehr "fleshed out" sein. Die Stichpunkte da erklären noch nicht genug. **

Wieso Micro Frontends?

Gleiche Gründe wie bei der Entscheidung für Microservice gegenüber Monolithen:

• Teamgröße
• Skalierbarkeit
• Wartbarkeit
• Unabhängigkeit bei Deployments

Headful Microservice

Der Klärungsbedarf sinkt gegenüber einer headless Lösung, wo ein einzelnes UI Team Inhalte abstimmen und umsetzen muss. Dieses Team kann sich als Flaschenhals entpuppen.

Weniger eng gekoppelte Teams --> weniger Abhängigkeiten dazwischen

Diese Schlussfolgerung gilt auch für UI!

Bezüglich Technologieabhängigkeit zwischen den Teams, muss Folgendes bedacht werden: Ein gemeinsames UI setzt zumindest auf dem Basislevel eine gemeinsame Technologiewahl voraus.

API vs BFF (Backends for Frontends)

Nichts ist in unserem Kontext stabiler als die Fachlichkeit. Dies bedeutet besondere Wichtigkeit für eine Service API.

Eine ähnliche Aussage wie die von Herrn Drotbohm: Man möchte keine Backend-Applikation für eine bestimmte Form des Frontends schreiben.

Es gibt drei allgemein akzeptierte Methoden zur Kommunikation zwischen Frontend und Backend MS:

• Frontends to Backends
  • Mehr Datenverkehr, da Internet verwendet wird
• Backend direct
  • Weniger Datenverkehr
  • Asynchron
• Backends for Frontends Schicht
  • BFF dürfen keine Business Logik beinhalten --> Dienen nur der Zusammenführung von Komponenten

Wiederverwendbare Komponenten

• Decomposed UI
  • Besteht aus Bestandteilen aus allen Microservices
• Shared UI
  • Teams können eigene UI Komponenten entwerfen, die in einem UI an unterschiedlichen Stellen eingesetzt werden können (Beispiel Widgets)
• Re-use versus Decomposition
  • Je fachspezifischer eine Komponente wird, desto schwieriger wird eine Wiederverwendbarkeit
  • Nicht komplizierter machen, als es nötig ist.
  • Wiederverwendbarkeit nur wenn folgende Bedinungen erfüllt sind:
    • Same Bounded Context
    • Same Users and Needs?
    • Cost of Recreating ist größer als Cost of Coupling
  • Wiederverwendung Kann Technologieabhängigkeiten mit sich bringen