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

Wieso Micro Frontends?

Gleiche Gründe wie bei der Entscheidung für MS gegenpber Monolithen:

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

Headful MS

Der Klärungsbedarf sinkt

Gegenüber einer headless Lösung, wo ein einzelnes UI Team Inhalte abstimmen und Umsetzen muss. Dieses Team wird im schlimmsten Fall zu einem Flaschenhals.

Weniger Teams --> weniger Abhängigkeiten dazwischen

Diese Schlussfolgerung gilt auch für UI!

Aber: Technologieabhängigkeit zwischen den Teams

Ein gemeinsames UI setzt eine gemeinsame Technologiewahl voraus.

API vs BFF

Fachlichkeit ist das Stabilste was man hat --> Service API ist wichtig!

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 MS
• 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 erfüllt ist: Same Bounded Context? - JA -> Same Users and NEeds? - Ja -> Cost of < > >

Coupling? --> Kann Technologieabhängigkeiten mit sich bringen

use before reuse