Mikrofronts auf Iframe
In einem Unternehmen wurde eine ausgewogene und bewusste CTO-Entscheidung getroffen, dass Mikrofronts mit Microservices gleichwertig sein und auf Iframes bereitgestellt werden sollten.
Als Argument wurde übrigens das Office 360-Produkt von Microsoft angegeben, das zuvor "<iframe />" für die oberen und seitlichen Menüs verwendete. Jetzt sind keine iframes da.
Gründe und Voraussetzungen für Mikrofronts
Einer der Hauptvorteile von Mikrofront-Enden ist die Aufteilung der Funktionalität des Monolithen in Teams, die Möglichkeit, End-to-End-Tests detaillierter durchzuführen, und der Verkauf von Software in Teilen (im Fall von Boxed-Lösungen).
Alle verfügbaren Anwendungen sind React SPA. Sie haben nichts gemeinsam außer Material UI, React Router v4 und dem Embryo UI-Kit als npm-Module.
Einige Anwendungen werden sowohl in einer eigenständigen Version als auch als Teil einer anderen Anwendung verwendet und bereitgestellt.
Mikrofronts wurden in große Funktionsblöcke unterteilt:
- Anwendungsheader. Routing zwischen Apps
- Dashboard-Anwendung. Mit Metriken und Widgets. Jedes Dashboard-Widget muss Teil der entsprechenden Anwendung sein (über einen Iframe verbunden).
- Die Anwendungen selbst. Einige von ihnen enthalten Teile voneinander (aber ohne Fanatismus und Rekursion)
Somit werden unabhängig voneinander unterschiedliche Freisetzungszyklen erhalten. Solange die Anwendungen der internen API folgen.
Problem # 0. Falsche Trennung der Mikrofronts
Leider wurden Mikrofronts nicht tief genug durchdacht. Ein Beispiel ist ein Online-Shop. Der Kaufknopf und der Einkaufswagen können an vielen Stellen verstreut sein, aber alle sind ein Mikrofront. Als Produktkarte in 10 Variationen und dem Bestellvorgang (wo Rechnungen und Adressen). All dies können separate Mikrofronts mit eigenen Freisetzungszyklen sein.
In Wirklichkeit stellte sich heraus, dass die Anwendungen sehr grob aufgeteilt waren. In Analogie zu einem Online-Shop erstellt ein Team den Warenkorb und die Checkout-Seite, das zweite Team den Rest (einschließlich der Warenkorbzähler auf allen anderen Seiten). Gleichzeitig verwendet jeder dieselbe Geschäftslogik, und die Schnittstelle wird auf der Ebene des UI-Kits oder der Material-UI-Bibliothek wiederverwendet.
Es stellte sich heraus, dass funktionale Anwendungen (grün und lila markiert) viel gemeinsam haben. Ein wesentlicher Teil der Geschäftslogik in diesen beiden Anwendungen musste in eine separate Mikrofront getrennt und verwendet werden. Tatsächlich gibt es bei weitem keine zwei solchen Anwendungen. Insgesamt gab es ungefähr sieben funktionale Anwendungen, die die Logik nicht auf der richtigen Ebene wiederverwenden.
Infolgedessen schlug die Zeitersparnis bei der Wiederverwendung von Anwendungen fehl. Die Vervielfältigung der Funktionalität blieb ebenfalls auf einem hohen Niveau. Die Verwendung von Mikrofront-Enden ohne Iframes oder Komponenten mit komplexerer Logik aus dem erweiterten UI-Kit könnte das Problem der doppelten Funktionalität lösen.
Problem Nr. 1. Fehlende Prozess-Orchestrierung
Dabei wurden viele Fragen zur Organisation von Microservices diskutiert. Wie sie miteinander kommunizieren, nach welchem Protokoll wurde die Organisation des Interaktionsprozesses zwischen Mikrofrontierten in den Hintergrund gedrängt.
Um alle CORS-Probleme ein für alle Mal zu neutralisieren, wurde beschlossen, Nginx zu pflanzen, das das Routing übernimmt. So hatte jeder Mikrofront und jeder Microservice eine eigene Adresse, zum Beispiel: Es bleibt die Frage, wie Anwendungen im Entwicklungsmodus getestet werden können. Wird jede Anwendung an einem anderen Port bereitgestellt?
https://domain.zone/dashboard
https://domain.zone/header
https://domain.zone/app1
https://domain.zone/app2
https://domain.zone/api1
https://domain.zone/api2
Hier kommt das Paket "http-proxy-middleware" zur Rettung, das in Verbindung mit der CRA konfiguriert werden kann. Es stellte sich heraus, dass nur die Hälfte der Front-End-Entwickler ein solches Setup einrichten konnte. Natürlich kann man hier niemandem die Schuld geben, aber ein solches Problem ist aufgetreten und muss organisatorisch gelöst werden.
Eine klare Versionierung aller Anwendungen mit einer Beschreibung der Funktionalität, der verfügbaren Methoden und der internen API ist ebenfalls erforderlich. Daher das nächste Problem: Dokumentation.
Problem Nr. 2. Fehlende interne API
Damit Anwendungen sehr gut miteinander interagieren können, ist eine Dokumentation erforderlich. Leider haben in unserem Fall nur Microservices Dokumentation. Und der Blick fiel nicht auf die Mikrofronts.
Dies ist ein sehr kritischer Teil des Systems bei verteilten Teams und sogar bei der Fluktuation.
Es ist auch notwendig, einen Mechanismus für die Kommunikation zwischen Anwendungen zu entwickeln. Hier kommt die "postMessage API" zur Rettung oder zum direkten Zugriff auf eine andere, die in fast jede React-Anwendung integriert ist - Redux. Was ist kein Nachrichtenbus? Aber dazu später mehr.
Problem Nr. 3. Iframe ist nicht flexibel genug
Es ist nichts Falsches daran, das Tag << iframe /> `zu verwenden. Es ist ein leistungsstarkes Tool mit integriertem Nachrichtenbus (postMessage API) und umfangreichen Sicherheitsanpassungen.
Im Fall von Mikrofronthends unterliegt <iframe /> jedoch vielen Einschränkungen. Eine davon ist die Unfähigkeit, eine Anwendung in mehreren Teilen der Seite wiederzuverwenden.
Anwendungen wiederverwenden
Im Fall einer Online-Shop-Analogie werden mit 10 Kaufschaltflächen 10 <iframe /> erstellt, dh 10 React-Apps werden ausgeführt. Dafür ist nicht genügend Speicher vorhanden. Dies ist einer der Gründe, warum eine Aufteilung der Anwendung in Teams nach Funktionen nicht möglich ist.
URL ist nicht als Statusverwaltung geeignet
Wir sind alle daran gewöhnt, Apps über URLs weiterzuleiten. Dies ist auch praktisch, wenn die Mikrofront als unabhängige Einheit verwendet wird. Zum Beispiel, wenn ein Teil der Hauptanwendung kohärent genug ist, um für sich allein nützlich zu sein. Dies ist natürlich kein einzigartiger Vorteil des iframe-Ansatzes, aber es ist recht einfach.
Hier ist ein Beispiel dafür, wie eine lila Anwendung von KDPV mit einer anderen URL als eigenständige Anwendung funktionieren kann:
Die Verwendung der URL-Iframe-Schnittstelle zum Ändern des Status der Mikrofront stellte sich in unserem Fall jedoch als unmöglich heraus: Die Mikrofront wird aufgrund der unvollständigen Integration der Verlaufs-API mit ihrem pushState von Grund auf neu geladen `und Reagieren Router - erhalten eine volle Seite refresh.
Außerhalb von "iframe" -Klick-Handlern
Stellen Sie sich vor, Sie erstellen ein Dropdown-Menü. Wie im obigen Diagramm: aus dem rosa Menü. Und schließen Sie es auch, indem Sie auf eine leere Stelle klicken. Bei einem Iframe müssen Sie die bedingte postMessage-API verwenden, da ein Out-Click aufgrund unterschiedlicher Fensterobjekte einfach nicht erkannt wird. Oder erstellen Sie einen Hack mit einem transparenten Hintergrund des vergrößerten iframe-Elements im Vollbildmodus.
Übrigens wird das Ändern der Größe des Iframes und das Anpassen der übergeordneten Anwendung auch umständlicher und komplexer.
Bonusproblem: Unangemessene Verwendung von Cookies
Dieses Problem hängt nicht direkt mit Mikrofronts zusammen, sondern bringt es auf die nächste Stufe des Wahnsinns.
Es wurde beschlossen, in die Autorisierungscookies nicht nur das Token, sondern auch die vollständige Liste der Rechte an bestimmten Teilen der Anwendung zu schreiben. All dies wurde von SHA verschlüsselt - ??? und in base64 konvertiert.
Infolgedessen überschritt die Cookie-Größe 8 KB, was der Standardwert für nodejs / nginx ist (oder 2 KB für die Größe eines Cookie-Datensatzes in Google Chrome), was zu einer komplexeren Serverkonfiguration führte (ohne CRA auswerfen können Sie nicht mit dieser Einstellung beginnen) auch um dieses große verschlüsselte Dataset in kleinere Cookie-Strings aufzuteilen.
Dies bedeutet, dass jede Anfrage an den Server, selbst um "favicon.ico" oder eine Liste der verfügbaren Menüabschnitte zu erhalten, mit einem zusätzlichen Header von beeindruckender Größe ausgestattet ist.
Fazit. Wie kann man dann mit Mikrofronts leben?
Zunächst müssen Sie sich natürlich entscheiden, ob Sie Mikrofronts benötigen. Oft löst ein ordnungsgemäß konfiguriertes und erweitertes UI-Kit in Form eines npm-Moduls das Problem sowohl unabhängiger Releases als auch des gleichen visuellen Stils.
- Verwenden Sie keinen Iframe. Dies vereinfacht nicht die Arbeit, sondern fügt nur Leistungsprobleme hinzu, wodurch die Möglichkeit, die Anwendung in Mikrofronts aufzuteilen, erheblich eingeschränkt wird. Das Rendern von SPA-Blöcken in speziell reservierte Tags ist eine viel effizientere Lösung.
- Prozess-Orchestrierung entwickeln: sowohl in der Produktion als auch für die Entwicklung. Nicht jeder Entwickler würde in die verwandte Branche des Routings und Proxys eintauchen wollen, als er beauftragt wurde, Schnittstellen aus vorgefertigten Blöcken zu vernieten.
- Entwickeln Sie einen Nachrichtenbus zwischen Anwendungen. Dies ist bei einem einzelnen globalen Raum - dem Fensterobjekt - viel einfacher.
- Erstellen Sie eine Dokumentation auf der Schnittstelle für die Interaktion von Anwendungen sowie deren Start und Konfiguration.