Micro-Frontends: Die bessere Art User Interfaces zu implementieren? Teil #2

Im ersten Teil unserer Blogserie Mirco-Frontends hatten wir den grundsätzlichen Nutzen des Einsatzes von Mirco-Frontends erläutert und die Vor- und Nachteile dieses Ansatzes abgewogen. Darüber hinaus waren wir auf die Herausforderungen eingegangen, die gemeistert werden müssen, um Mirco-Frontends erfolgreich einzusetzen und hatten als ersten Ansatz iFrames vorgestellt. In diesem Teil wollen wir nun drei weitere Ansätze besprechen: Multi-Page, Varnish Cache & Esi Lang sowie „Blackbox“ React components.

Multi-Page = Multi-App

Eine einfache aber einleuchtende Idee. Hier wird ein Micro-Frontend als Subpage einer Anwendung definiert. Über Navigationsevents wechselt man zwischen Anwendungen hin und her. Dieser Anwendungswechsel ist wie ein kompletter Seitenrefresh zu sehen, bei dem das neue Micro-Frontend neu geladen und initialisiert wird. Kommunikation zwischen den Micro-Frontends kann also über Backend-Systeme realisiert werden und die Technologieverträglichkeit ist somit ebenfalls gegeben. Allerdings sind diese ‚lang' dauernden Seitenwechsel für den Benutzer nervig. Mittlerweile ist man an Single-Page-Apps gewöhnt bei denen der Seitenwechsel fast augenblicklich geschieht. Der Schnitt der Micro-Frontends ist hier sehr groß gewählt. Das birgt die Gefahr einige Komponenten (z.B. Navigationsleisten und Footer) mehrfach zu entwickeln. Dieses Problem kann natürlich durch Technologievorgaben und Komponentenlibraries behoben werden. Die Navigation zwischen den Applikationen werden von den Micro-Apps selbst durch relative Links auf andere Mirco-Apps vorgenommen. Damit alles unter derselben Domain gehostet werden kann wird ein Proxy vorgelagert.

 Multi-Page = Multi App

Multi-Page = Multi App

Varnish Cache & ESI Lang

Diese Lösung nutzt den Reverse-Proxy Varnish Cache, der bei Webseiten sehr verbreitet ist, da er statische Zugriffe sehr performant cachen kann. Der Varnisch Cache unterstützt, wie auch nginx, die ESI (Edge Site Integration) Language Definition. Damit ist es möglich, eine Art Template zu erstellen, deren Inhalte durch Varnish Cache zusammengesetzt und ausgeliefert werden.

 Kleiner Exkurs in die ESI Language Specification

Kleiner Exkurs in die ESI Language Specification

Die vorhandene Language Specification ist der große Pluspunkt für diesen Ansatz. ESI ist leider nicht so bekannt und weit verbreitet. Durch den Varnish Cache ist die Performance beim Laden statischer Elemente gegeben, allerdings schützt das nicht vor Namens- und Versionskonflikten der Assets. Daraus können implizite Abhängigkeiten zwischen den Fragmenten entstehen, die letztendlich den Wartungsaufwand erhöhen.

"Blackbox" React components

Bei diesem React-spezifischen Ansatz für Micro-Frontends werden einzelne React-Applikationen in einer Komponente gewrappt, die in einer allumfassenden React-Applikation verwendet werden kann. Die Micro-Frontends werden über ihre API und die Component-Properties gesteuert. Das Ergebnis ist eine riesige React-Anwendung, die letztendlich doch wieder einen gemeinsamen Build- und Deploymentprozess durchläuft. Die einzelnen Teams sind bei diesem Ansatz nicht frei in ihrer Technologiewahl. Diese ist durch den Ansatz vorgegeben. Ob man bei diesem Ansatz von einem Micro-Frontend-Ansatz sprechen kann, ist daher fraglich.

blackbox-react-components.png

Im dritten und abschließende Blogpost (Anfang Januar 2018) befassen wir uns mit drei weiteren interessanten Ansätzen, um dann eine abschließende Bewertung des Mirco-Frontend-Ansatzes vorzunehmen.

Weiterführende Links:

https://allegro.tech/2016/03/Managing-Frontend-in-the-microservices-architecture.html

https://www.w3.org/TR/esi-lang