Micro-Frontends - Die bessere Art User Interfaces zu implementieren?

Die Funktionalität von Anwendungen wächst stetig und die gemeinsame Arbeit mehrerer Teams an einer gemeinsamen Codebasis ist in einigen Fällen nicht mehr praktikabel. Am besten ist es, wenn die Teams weitestgehend unabhängig voneinander arbeiten können und die fachliche Komplexität nicht zu hoch ist. Einige ahnen jetzt schon auf welches Buzzword hier abgezielt wird – Micro Services. Micro-Services sind momentan vor allem im Backend ein Thema. Wenn wir den Ansatz in das Frontend portieren wird daraus Micro-Frontends.

Das Frontend wird dabei in seine Seiten oder Funktionen unterteilt. Diese Blöcke werden von eigenständigen Teams implementiert und deployed. Das erhöht sowohl die Testbarkeit, bietet die Möglichkeit die optimalen Technologien für jedes Micro-Frontend auszuwählen und erleichtert die parallele Entwicklung an einer großen Webseite. Zudem erhöht sich die Unabhängigkeit der Micro-Frontends im Fehlerfall. Ein Fehler in einem Micro-Frontend sollte keine Auswirkungen auf andere Frontendblöcke haben.

Diese Vorteile gibt es, wie so oft, nicht umsonst. Durch den Micro-Frontend-Ansatz erhöht sich der Betriebsaufwand, da mehrere Micro-Frontends auf ihrer eigenen Hardware betrieben werden müssen. Außerdem erhöht sich dadurch die technische Komplexität und Refactorings oder Restrukturierungen können komplizierter werden. Durch das Laden mehrerer Frontends in einer Webseite leidet zudem die Performance.

Kurz zusammengefasst:

Pro

  • unabhängig, kann einfach und oft deployed werden
  • hohe Testbarkeit

  • unabhängige Technologiestacks

  • unabhängig im Fehlerfall

  • parallele Entwicklung

Contra

  • erhöhter Betriebsaufwand 

  • erhöhte Komplexität (Infrastruktur, Kommunikation, etc.)

  • schwächere Performance

  • Refactorings oder Restrukturierungen können kompliziert werden

Herausforderungen

Um erfolgreich Micro-Frontends zu verwenden müssen ein paar Herausforderungen gemeistert werden, die nicht alle mit derselben Qualität gelöst werden können. Möglicherweise die Lösung einiger der folgenden sieben Punkte so aufwendig, dass man lieber auf den ein oder anderen Vorteil von Micro-Frontends verzichtet.

  1. Wie schneidet man die Micro-Frontends/-Apps?
    Beschreibt ein Micro-Frontend eine Subpage einer Multi-Page-Applikation oder definiert man es enger, als UI-Komponente? Der Schnitt bzw. die Definition eines Micro-Frontends wirkt sich eventuell auch auf die Technologiewahl oder die Micro-Frontend-Architektur aus.
  2. Inter-Frontend-Kommunikation
    Das ist vor allem ein Problem, wenn man Micro-Frontends im Sinne von einzelnen UI-Blöcken definiert. Nehmen wir an ich halte mich in einem Online-Shop auf und ein Micro-Frontend umfasst die Produktliste und ein anderes den Warenkorb. Wähle ich nun ein Produkt aus der Liste zum Kauf aus, so soll sich auch mein Warenkorb visuell aktualisieren. In einer monolithischen Architektur einfach zu lösen, je nach Micro-Frontend-Architektur eine Herausforderung.
  3. Einheitliches Look & Feel
    Die einzelnen Micro-Frontends können trotz Styleguide individuelle Abweichungen aufweisen, die sich störend auf das Gesamtbild auswirken. Wie können Änderungen am Styleguide zeitnah auf alle Micro-Apps angewandt werden
  4. Routing
    Bei einem Navigationsevent muss sichergestellt werden das der Benutzer auch auf der Seite landet die er nutzen möchte. Außerdem muss sichergestellt sein, dass eine bestimmte Route nicht mehrfach belegt ist.
  5. Technologieverträglichkeit
    Können mehrere Apps derselben Technology auf einer Seite platziert werden? Wie stelle ich sicher das Subpages diesen Constraint beachten? Aber auch mehrere Versionen derselben Technologie können möglicherweise Probleme bereiten.
  6. Wiederverwendbarkeit
    Manche UI-Komponenten werden an vielen Stellen verwendet, wie kann ich diese in verschieden Micro-Frontends wiederverwenden. Eventuell gibt es dabei UI-technologische Einschränkungen oder eben Code-Duplikation.
  7. Performance
    Mehrere Micro-Apps auf einer Seite bedeutet auch, dass mehr Dateien nachgeladen werden müssen und mehrere Anwendungen initialisiert werden müssen. Die Micro-Apps müssen dementsprechend performant sein und die ausgelieferten JavaScript- und CSS-Dateien auf ein Minimum, sowohl in Anzahl als auch Größe, beschränkt werden

Micro-Apps in iFrames

Die Idee iFrames zu benutzen um eine Webanwendung in einer anderen einzubetten ist schon recht alt und ist vielen Lesern wahrscheinlich als erster Lösungsansatz in den Sinn gekommen. Sie hat den Vorteil, dass die einzelnen Micro-Frontends einen eigenen DOM-Baum haben und fast so agieren können als würden sie eigenständig ausgeführt werden. So wäre es auch möglich mehrere Apps auf einer Page zu vereinen, das Problem etwaiger Technologieunverträglichkeiten wird dadurch neutralisiert. Das geht aber zu Lasten der Performance und Bedienbarkeit. Die Kommunikation zwischen den Apps ist erschwert und funktioniert entweder über Backend-Services oder Window.postmessage APIs. Zusätzlich gibt es in einigen Browsern die Einschränkung das es nicht mehr als zwei Level von ineinander verschachtelten iFrames geben kann. Das Routing zwischen Subpages muss von der ‚Mutter-Seite' oder einem vorgelagerten Proxy übernommen werden.

Strukturschema: Mirco-Apps in iFrames

Strukturschema: Mirco-Apps in iFrames

Die iFrame-Lösung ist die erste, aber bei Weitem nicht die einzige Möglichkeit Micro-Frontends umzusetzen. Weitere Optionen präsentieren wir im nächsten Blogpost unserer Reihe.