Micro-Frontend-Migrationsreise – Teil 1: Design

In der heutigen schnelllebigen digitalen Welt, in der Agilität und Skalierbarkeit von entscheidender Bedeutung sind, suchen Unternehmen ständig nach Möglichkeiten, die Leistung und Wartbarkeit ihrer Webanwendungen zu verbessern.

Ein beliebter Ansatz zum Erreichen dieser Ziele ist die Migration von einer monolithischen Architektur zu einer verteilten Architektur (oder einem Mikro-Frontend). In dieser Artikelserie „Micro-Frontend Migration Journey“ teile ich meine persönlichen Erfahrungen mit der Durchführung einer solchen Migration während meiner Zeit bei AWS.

HAFTUNGSAUSSCHLUSS : Bevor wir beginnen, ist es wichtig zu beachten, dass dieser Artikel zwar meine persönlichen Erfahrungen wiedergibt, ich jedoch keine proprietären oder internen Details zu Tools, Technologien oder spezifischen Prozessen bei AWS oder einer anderen Organisation offenlegen kann.

Ich bin bestrebt, die rechtlichen Verpflichtungen einzuhalten und sicherzustellen, dass sich dieser Artikel ausschließlich auf die allgemeinen Konzepte und Strategien konzentriert, die mit der Micro-Frontend-Migration verbunden sind.

Der Zweck besteht darin, Erkenntnisse und gewonnene Erkenntnisse bereitzustellen, die in einem breiteren Kontext anwendbar sind, ohne dass vertrauliche Informationen preisgegeben werden.

Motivation zur Migration

Ich habe durch den Artikel auf Martin Fowlers Blog etwas über Mikro-Frontends gelernt (ich vermute, dass es viele von Ihnen auch tun). Es wurden verschiedene Möglichkeiten vorgestellt, eine Mikro-Frontend-Architektur auf Framework-unabhängige Weise zu erstellen.

Als ich mich eingehender mit dem Thema befasste, wurde mir klar, dass unsere bestehende monolithische Architektur zu einem erheblichen Engpass für die Produktivität unseres Teams wurde und die Gesamtleistung unserer Anwendung beeinträchtigte.

Einer der Schlüsselfaktoren, die mich dazu bewogen haben, über eine Migration nachzudenken, war die zunehmende Paketgröße unserer Anwendung.

Nachdem ich im Sommer 2020 eine gründliche Bundle-Analyse durchgeführt hatte, stellte ich fest, dass die Bundle-Größe (gzippt) seit der ersten Einführung Anfang 2019 von 450 KB auf 800 KB (geparst sind es fast 4 MB) angewachsen war – fast das Doppelte der ursprünglichen Größe.

Angesichts des Erfolgs unseres Dienstes und der Prognose seines weiteren Wachstums war klar, dass dieser Trend anhalten und sich weiter auf die Leistung und Wartbarkeit unserer Anwendung auswirken würde.

Obwohl ich vom Konzept der Mikro-Frontends begeistert war, erkannte ich auch, dass wir aufgrund spezifischer Herausforderungen, denen wir gegenüberstanden, noch nicht bereit waren, sie einzuführen:

1. Kleine Organisationsstruktur: Zum Zeitpunkt meiner Analyse war unsere Organisation relativ klein und ich war der einzige Vollzeit-Frontend-Ingenieur im Team. Die Migration auf eine Mikro-Frontend-Architektur erforderte erhebliche Investitionen in die Organisationsstruktur und die betrieblichen Grundlagen.

   
   

   Es war von entscheidender Bedeutung, über eine ausgereifte Struktur zu verfügen, die die verteilte Architektur effektiv bewältigen und die Abhängigkeiten zwischen verschiedenen Frontend-Komponenten widerspiegeln kann.

   
   

2. Eingeschränkter Geschäftsbereich: Obwohl Mikro-Frontends basierend auf begrenzten Kontexten und Geschäftsfunktionen aufgeteilt werden können (mehr erfahren Sie im Beitrag „ Domänengesteuertes Design in der Mikro-Frontend-Architektur“ ), war unser Kerngeschäftsbereich nicht umfangreich genug, um eine vollständige Entkopplung zu rechtfertigen mehrere Mikro-Frontends. Es gab jedoch sichtbare Grenzen innerhalb der Anwendung, deren Herausarbeitung und Übergang zu einer verteilten Architektur sinnvoll war.

Angesichts dieser Faktoren wurde mir klar, dass ein schrittweiser Ansatz notwendig war. Anstelle einer vollständigen Migration auf Mikro-Frontends wollte ich bestimmte Bereiche innerhalb unserer Anwendung identifizieren, die von einer verteilten Architektur profitieren könnten.

Dies würde es uns ermöglichen, Leistungs- und Skalierbarkeitsprobleme anzugehen, ohne die gesamte Organisationsstruktur zu stören oder die Integrität unseres Geschäftsbereichs zu gefährden. Es würde uns auch etwas Zeit geben, das Team zu vergrößern und die Geschäftsrichtung zu beobachten.

Bitte beachten Sie, dass es möglicherweise nicht die beste Idee ist, das Leistungsproblem (Bundle-Größe) der App nur durch die Verwendung der Mciro-Frontend-Architektur zu lösen. Es wäre besser, mit einer verteilten Monolith-Architektur zu beginnen, die stattdessen Lazy Loading (dynamische Importe) nutzt.

Darüber hinaus denke ich, dass es Probleme mit der Bundle-Größe besser lösen würde als die Mikro-Frontend-Architektur, wenn man bedenkt, dass die Mikro-Frontend-Architektur höchstwahrscheinlich über einen gemeinsamen Code verfügt, der nicht in Anbieterblöcke aufgeteilt wäre, und dieser in das Anwendungspaket integriert wäre ( Das ist einer der Nachteile einer solchen verteilten Architektur – Sie müssen einen Kompromiss zwischen dem, was wann und wie geteilt werden soll, eingehen.

Allerdings lässt sich eine verteilte Monolith-Architektur nicht so gut skalieren wie ein Mikro-Frontend. Wenn Ihr Unternehmen schnell wächst, wird wahrscheinlich auch Ihr Team im gleichen Tempo wachsen.

Es wäre unbedingt erforderlich, die Codebasis in verschiedene Eigentumsbereiche aufzuteilen, die von verschiedenen Teams kontrolliert werden.

Und jedes Team muss seine eigenen Veröffentlichungszyklen haben, die unabhängig von anderen sind. Jedes Team wird es zu schätzen wissen, wenn sich seine Codebasis ausschließlich auf seine Domäne konzentriert und schnell erstellt wird (Code-Isolation -> bessere Wartbarkeit/weniger zu wartender Code). Build -> bessere Testbarkeit/weniger Tests für Wartung und Ausführung).

Der Anfang

Um die Unterstützung der Führung zu gewinnen, habe ich ein überzeugendes technisches Visionsdokument erstellt, das eine umfassende Leistungsanalyse, einschließlich Web-Vital-Metriken, umfasste und die verschiedenen Phasen der Migration hin zu verteilten Frontends skizzierte.

Eine der Zwischenphasen dieser Migration bestand darin, eine verteilte monolithische Architektur zu etablieren, in der mehrere Module/Widgets asynchron über Lazy-Loading-Techniken bereitgestellt werden konnten, während gleichzeitig eine gemeinsame Infrastruktur wie ein S3-Bucket und CDN zwischen dem Kerndienst und den Widgets genutzt werden konnte .

Wie ich in meinem vorherigen Artikel dargelegt habe, besteht die Hauptidee dieser Art von Dokument darin, die Zukunft so zu beschreiben, wie man sie sich wünscht, sobald die Ziele erreicht und die größten Probleme gelöst sind. Es geht nicht um den Ausführungsplan!

Fast ein Jahr später war es endlich an der Zeit, meinen Micro-Frontend-Migrationsplan in die Tat umzusetzen. Mit der bevorstehenden Expansion in eine neue Domäne und einem größeren Team, das uns zur Verfügung stand, waren wir für die Durchführung der Migration gut gerüstet.

Es fühlte sich wie eine einmalige Gelegenheit an, die wir uns nicht entgehen lassen durften.

Denn wer auf die monolithische Architektur beschränkt bleiben würde, würde bedeuten, sich ständig mit deren Grenzen auseinanderzusetzen.

Der begrenzte Zeitrahmen für die Expansion in eine neue Domäne diente als Katalysator und trieb uns dazu, sofort eine skalierbarere und wartbarere Architektur aufzubauen, anstatt kurze und langsame Iterationen durchzuführen!

Um die Migration durchzuführen und gleichzeitig die Arbeit in der neuen Domäne zu erledigen, haben wir die Teams in zwei dedizierte Gruppen aufgeteilt. Die Feature-Arbeit, die eine höhere Priorität hatte, erforderte mehr Ressourcen und musste schneller iteriert werden.

Um die Integrität und das umfassende Verständnis des Migrationsprozesses sicherzustellen, war es sinnvoll, ein kleines, dediziertes Team speziell für die Abwicklung der Migration zu beauftragen.

Wir konnten jedoch nicht mit der Feature-Arbeit fortfahren, ohne zuvor sicherzustellen, dass sich das Micro-Frontend-Konzept als erfolgreich erweisen würde.

Um Risiken zu mindern und einen klaren Fahrplan bereitzustellen, war es von entscheidender Bedeutung, ein Entwurfsdokument auf niedriger Ebene zu erstellen, das präzise Schätzungen und eine gründliche Risikobewertung enthielt. Dieses Dokument diente als Blaupause und skizzierte die notwendigen Schritte und Überlegungen für die Migration.

Der entscheidende Meilenstein in diesem Prozess war die Entwicklung eines Proof-of-Concept, der die erfolgreiche Integration aller Komponenten gemäß dem Design demonstrieren sollte.

Dieser Meilenstein mit dem treffenden Namen „Point of no Return“ zielte darauf ab, die Machbarkeit und Wirksamkeit der Mikro-Frontend-Architektur zu validieren.

Obwohl ich hinsichtlich des Erfolgs der Migration optimistisch war, war es wichtig, sich auf Eventualitäten vorzubereiten. Deshalb habe ich einen Plan B entwickelt, der als Backup-Strategie für den Fall diente, dass das ursprüngliche Konzept nicht die gewünschten Ergebnisse brachte.

Dazu gehörte die Zuweisung zusätzlicher sieben Tage in den Kostenvoranschlägen, um mich ins Kissen weinen zu lassen, sowie ein paar Tage, um einen neuen Funktionsmoduleintrag per Lazy-Loading mit dem Kern zu verbinden (erinnern Sie sich an den verteilten Monolithen?).

Das Design

Beim Entwerfen von Mikro-Frontends gibt es im Allgemeinen drei Kompositionsansätze, die sich jeweils darauf konzentrieren, wo die Laufzeit-App-Auflösung stattfindet. Das Schöne an diesen Ansätzen ist, dass sie sich nicht gegenseitig ausschließen und je nach Bedarf kombiniert werden können.

Serverseitige Komposition

Die Grundidee besteht darin, einen Reverse-Proxy-Server zu nutzen, um Micro-Frontend-Bundles pro Seite aufzuteilen und einen harten Neuladen der Seite basierend auf der Routen-URL durchzuführen.

Vorteile:

• Einfach umzusetzen

Nachteile:

• Der globale Status wird nicht zwischen den Micro-Frontend-Apps synchronisiert. Dies war für uns ein klarer No-Go-Punkt, da auf der Client-Seite langwierige Hintergrundoperationen durchgeführt wurden.

  
  

  Man könnte argumentieren, dass wir einen Snapshot der „Warteschlange“ dieses Vorgangs im lokalen Speicher speichern und nach dem Neuladen daraus lesen könnten, aber aus Sicherheitsgründen konnten wir dies nicht implementieren.

  
  

  Dies ist nur ein Beispiel für einen globalen Status, aber hier ist ein weiteres Beispiel dafür, wie er aussehen kann: Status der Seitennavigationsfelder (erweitert/reduziert), Toastnachrichten usw.

• Die harte Aktualisierung beim Navigieren durch Mikro-Apps ist nicht sehr kundenfreundlich. Es gibt eine Möglichkeit, gemeinsam genutzten HTML-Code mithilfe von Servicemitarbeitern zwischenzuspeichern, die Wartung ist jedoch zusätzlich kompliziert.

• Zusätzliche Betriebs- und Wartungskosten für die Infrastruktur: Proxyserver für jede Micro-Frontend-App (dies kann vermieden werden, wenn sie direkt vom CDN gelesen wird), separate Infrastruktur zur Bereitstellung gemeinsamer (Hersteller-)Abhängigkeiten, die von mehreren Seiten wiederverwendet werden können, und zwar ordnungsgemäß von Browsern zwischengespeichert.

Randseitige Komposition

Ein weiterer Ansatz zur Mikro-Frontend-Komposition ist die Edge-Side-Komposition, bei der Mikro-Frontends auf der Randschicht, beispielsweise einem CDN, kombiniert werden. Beispielsweise unterstützt Amazon CloudFront die Lambda@Edge- Integration und ermöglicht die Verwendung eines gemeinsamen CDN zum Lesen und Bereitstellen der Micro-Frontend-Inhalte.

Vorteile:

• Weniger zu wartende Infrastrukturteile: Keine Proxy-Server erforderlich, separate CDNs für jede Mikro-App

• Nahezu unbegrenzte Skalierung durch serverlose Technologie

• Bessere Latenz im Vergleich zu eigenständigen Proxyservern

Nachteile:

• Die Kaltstartzeit könnte zum Problem werden

• Lambda@Edge wird nicht in allen AWS-Regionen unterstützt, wenn Sie eine multiregionale (isolierte) Infrastruktur benötigen

Clientseitige Komposition

Die clientseitige Komposition ist ein weiterer Ansatz für die Mikro-Frontend-Architektur, der clientseitige Mikro-Frontend-Orchestrierungstechniken nutzt, die von der Serverimplementierung entkoppelt sind.

Der Hauptakteur in dieser Architektur ist eine Container-(Shell-)Anwendung, die die folgenden Verantwortlichkeiten hat:

• Lösung übergreifender Probleme: Die Containeranwendung verwaltet das zentrale App-Layout, die Site-Navigation, die Fußzeile und das Hilfefeld. Die Integration mit Mikro-Frontends mit übergreifenden Anliegen erfolgt über einen Event-Bus, bei dem synthetische Ereignisse innerhalb des globalen Fensterbereichs gesendet und verarbeitet werden.

• Orchestrierung von Mikro-Frontends: Die Container-App bestimmt, welches Mikro-Frontend-Bundle wann geladen werden soll, basierend auf den Anforderungen der Anwendung und Benutzerinteraktionen.

• Zusammenstellen globaler Abhängigkeiten: Die Container-App stellt alle globalen Abhängigkeiten wie React, SDKs und UI-Bibliotheken zusammen und stellt sie als separates Bundle (vendor.js) bereit, das von den Mikro-Frontends gemeinsam genutzt werden kann.

Die allgemeine Idee besteht darin, dass jedes Micro-Frontend-Bundle zwei Arten von Asset-Dateien erzeugen würde:

• {hash}/index.js: Dies dient als Einstiegspunkt für die Micro-Frontend-Anwendung, wobei der Hash eine eindeutige Kennung für den gesamten Build darstellt.

  
  

  Der Hash fungiert als Präfixschlüssel für jedes Bundle im S3-Bucket. Es ist wichtig zu beachten, dass zwar mehrere Einstiegspunkte vorhanden sein können, der Hash jedoch für alle gleich bleibt.

• manifest.json: Dies ist eine Manifestdatei, die Pfade zu allen Einstiegspunkten für die Micro-Frontend-Anwendung enthält. Diese Datei verbleibt immer im Stammverzeichnis des S3-Buckets, sodass der Container sie leicht erkennen kann.

  
  

  Ich empfehle, die Versionierung dieser Datei im S3-Bucket zu aktivieren, um Änderungen besser beobachten zu können. Wenn Sie Webpack zum Erstellen Ihres Projekts verwenden, empfehle ich dringend WebpackManifestPlugin , das Ihnen die ganze schwere Arbeit abnimmt.

Der Container kennt nur die Micro-Frontend-Asset-Quelldomänen-URL (CDN-Ursprung) basierend auf der Stufe und der Region. Beim ersten Laden der Seite lädt der Container die Manifestdatei für jede Micro-Frontend-Anwendung herunter.

Die Manifestdatei ist sehr klein (ca. 100 Byte), um die Ladezeit der Seite nicht zu beeinträchtigen, und lässt sich auch dann gut skalieren, wenn mehrere Mikro-Frontends in einem Container zusammengefasst werden. Es ist wichtig, die Manifestdatei im Cache-Speicher des Browsers als unveränderlich zu betrachten, um aggressives Caching zu verhindern.

Die Auswahl der richtigen Orchestrierungsbibliothek stellt bei dieser Komposition die größte Herausforderung dar und wird im folgenden Kapitel besprochen.

Vorteile:

• Agnostisch gegenüber der Serverimplementierung: Dieser Ansatz kann ohne spezifische Serveranforderungen implementiert werden und bietet Flexibilität bei der verwendeten Backend-Technologie. Wie im Bild oben gezeigt, können Sie sogar keinen Server haben

• Beibehaltung des globalen Status: Durch die Verwendung einer Container-(Shell-)App kann der globale Status beim Wechsel zwischen Mikro-Frontends beibehalten werden. Dies gewährleistet ein nahtloses Benutzererlebnis und vermeidet Kontextverluste bei Übergängen.

• Dezentraler Ansatz: Jedes Mikro-Frontend kann unabhängig entscheiden, welche Daten an den Browser gesendet werden, um sich selbst zu booten. Die Container-App folgt einfach einem klar definierten Vertrag, was eine größere Autonomie und Modularität ermöglicht.

• Einfache lokale Einrichtung: Asset-Quellen können je nach Entwicklungsbedarf problemlos zwischen Produktions- und lokalen URLs angepasst werden. Die Manifestdatei hilft der Container-App, die erforderlichen Mikro-Frontends zu erkennen und zu laden. Entwickler können sich darauf konzentrieren, nur den Container und die spezifischen Mikro-Frontends auszuführen, an denen sie arbeiten.

Nachteile:

• Mehr Netzwerk-Hops zum Abrufen der Manifestdatei: Da der Container die Manifestdatei für jedes Mikro-Frontend abrufen muss, kann es im Vergleich zu anderen Kompositionsansätzen zu zusätzlichen Netzwerkanforderungen und potenzieller Latenz kommen. Dies kann abgemildert werden, indem das gesamte Manifest beim ersten Laden der Seite im Voraus geladen wird oder indem einige Vorladetechniken eingeführt werden.

• Einhaltung eines gemeinsamen Vertrags: Jedes Mikro-Frontend muss einen gemeinsamen Vertrag für die Erstellung von Builds einhalten. Dies kann durch gemeinsame Konfigurationen und standardisierte Entwicklungspraktiken erleichtert werden, um die Konsistenz über die Mikro-Frontends hinweg sicherzustellen (mehr dazu in den folgenden Abschnitten).

Hybride Komposition

Wie ich bereits in diesem Kapitel erwähnt habe, können alle diese Kompositionsmuster innerhalb derselben Shell-Anwendung gemischt und angepasst werden. Hier ist ein Beispiel, wie es aussehen kann:

Empfehlung

Ich empfehle, zunächst mit einem homogenen Ansatz zu beginnen – wählen Sie ein Kompositionsmuster, das besser zu Ihnen passt, und beginnen Sie mit dem Aufbau der Infrastruktur darum herum.

Für uns war die clientseitige Komposition die beste Option, aber für die Zukunft haben wir darüber nachgedacht, einige Regionen auf die Edge-seitige Orchestrierung umzustellen (basierend auf der Verfügbarkeit von Lambda@Edge).

Auswahl der Orchestrierungsbibliothek

Wenn es um die Implementierung der clientseitigen Komposition in einer Mikro-Frontend-Architektur geht, ist die Auswahl der richtigen Orchestrierungsbibliothek eine entscheidende Entscheidung.

Die ausgewählte Bibliothek wird eine entscheidende Rolle bei der Verwaltung des dynamischen Ladens und der Koordination von Mikro-Frontends innerhalb der Containeranwendung spielen.

Es gibt mehrere beliebte Orchestrierungsbibliotheken, jede mit ihren eigenen Stärken und Überlegungen.

Single-Spa

Single-spa ist eine weit verbreitete Orchestrierungsbibliothek, die einen flexiblen und erweiterbaren Ansatz für die Mikro-Frontend-Komposition bietet. Es ermöglicht Entwicklern, eine Shell-Anwendung zu erstellen, die das Laden und Entladen mehrerer Mikro-Frontends orchestriert.

Single-SPA bietet eine detaillierte Kontrolle über Lebenszyklusereignisse und unterstützt verschiedene Frameworks und Technologien.

Vorteile:

• Framework-unabhängig: Die Bibliothek funktioniert gut mit verschiedenen Frontend-Frameworks wie React, Angular, Vue.js und mehr.

• Flexible Konfiguration: Es bietet leistungsstarke Konfigurationsoptionen für Routing, Lazy Loading und gemeinsame Abhängigkeiten.

• Robustes Ökosystem: Single-SPA verfügt über eine aktive Community und ein reichhaltiges Ökosystem an Plugins und Erweiterungen.

Nachteile:

• Lernkurve: Der Einstieg in Single-Spa erfordert möglicherweise ein gewisses anfängliches Lernen und Verständnis seiner Konzepte und APIs.

• Komplexität der Anpassung: Mit zunehmender Komplexität der Mikro-Frontend-Architektur kann die Konfiguration und Verwaltung der Orchestrierung zu einer Herausforderung werden.

Qiankun

Qiankun ist eine leistungsstarke Orchestrierungsbibliothek, die vom Team von Ant Financial (Alibaba) entwickelt wurde. Für die Komposition wird ein partieller HTML-Ansatz verwendet. Auf der Seite der Micro-Frontend-App wird ein einfaches HTML-Snippet mit allen zu ladenden Einstiegspunkten erstellt.

Nach der Nutzung dieser HTML-Datei übernimmt der Container die gesamte Orchestrierung und stellt die App bereit. In dieser Konfiguration spielt partielles HTML die Rolle einer Manifestdatei, über die ich im vorherigen Kapitel gesprochen habe.

Vorteile:

• Framework-unabhängig: Qiankun unterstützt verschiedene Frontend-Frameworks, darunter React, Vue.js, Angular und mehr.

• Vereinfachte Integration: Qiankun bietet eine Reihe benutzerfreundlicher APIs und Tools zum Erstellen und Verwalten von Mikro-Frontends.

• Skalierbarkeit und Leistung: Qiankun bietet effiziente Mechanismen für Code-Sandboxing, Zustandsisolation und Kommunikation zwischen Mikro-Frontends.

Nachteile:

• Abhängigkeitskonflikte: Die Verwaltung gemeinsamer Abhängigkeiten und die Sicherstellung der Kompatibilität zwischen Mikro-Frontends erfordern möglicherweise eine sorgfältige Konfiguration und Überlegung.

• Lernkurve: Während Qiankun umfangreiche Dokumentation bereitstellt, kann die Einführung einer neuen Bibliothek eine Lernkurve für Ihr Entwicklungsteam mit sich bringen.

• Über die Leitung gesendete redundante Daten: Das teilweise HTML-Snippet enthält redundante Daten (Body, Meta, DOCTYPE-Tags), die über das Netzwerk gesendet werden müssen.

Modulverbund

Module Federation , eine von Webpack bereitgestellte Funktion, hat in der Webentwicklungs-Community große Aufmerksamkeit und Hype erregt. Diese Technologie ermöglicht es Entwicklern, Code zur Laufzeit zwischen mehreren Anwendungen auszutauschen, was sie zu einer attraktiven Option für die Erstellung von Mikro-Frontends macht.

Aufgrund seiner nahtlosen Integration mit Webpack und der Laufzeitflexibilität ist Module Federation zu einer beliebten Wahl für die Verwaltung und Orchestrierung von Mikro-Frontends geworden.

Vorteile:

• Nahtlose Integration mit Webpack: Wenn Sie Webpack bereits als Build-Tool verwenden, vereinfacht die Nutzung von Module Federation den Einrichtungs- und Integrationsprozess.

• Laufzeitflexibilität: Module Federation ermöglicht das dynamische Laden und Teilen von Abhängigkeiten und bietet so Flexibilität bei der Verwaltung von Mikro-Frontends.

Nachteile:

• Eingeschränkte Framework-Unterstützung: Obwohl Module Federation mit mehreren Frontend-Frameworks kompatibel ist, sind für bestimmte Anwendungsfälle möglicherweise zusätzliche Konfigurationen oder Problemumgehungen erforderlich.

• Community-Unterstützung: Module Federation ist eine relativ neue Technologie, die als Kern-Plugin in Webpack 5 veröffentlicht (und später auf v4 zurückportiert) wurde. Die Next.js-Bibliothek ist ebenfalls neuer und wurde kürzlich als Open Source veröffentlicht. Wie bei allen neuen Tools gibt es möglicherweise eine kleinere Community und weniger Support. Es ist wichtig, diesen Faktor zu berücksichtigen, wenn Sie knappe Fristen haben oder damit rechnen, auf Fragen zu stoßen, auf die es keine sofort verfügbaren Antworten gibt.

Abschluss

In diesem ersten Teil der Reihe „Micro-Frontend Migration Journey“ haben wir die Motivation hinter der Migration von einem Web-Monolithen zu einer verteilten Architektur und die ersten Schritte besprochen, die unternommen wurden, um die Idee der Führung zu verkaufen.

Wir haben die Bedeutung eines technischen Visionsdokuments untersucht, das eine detaillierte Leistungsanalyse präsentiert und die verschiedenen Phasen der Migration beschreibt.

Anschließend befassten wir uns mit den Designüberlegungen für Mikro-Frontends und diskutierten drei Ansätze: serverseitige Komposition, Edge-seitige Komposition und clientseitige Komposition.

Jeder Ansatz hat seine Vor- und Nachteile, und die Wahl hängt von verschiedenen Faktoren wie der Synchronisierung des globalen Status, dem Kundenerlebnis, der Komplexität der Infrastruktur und dem Caching ab.

Darüber hinaus haben wir beliebte Orchestrierungsbibliotheken wie Single-Spa, Qiankun und Module Federation untersucht und deren Funktionen, Vorteile und potenzielle Herausforderungen hervorgehoben.

Begleiten Sie mich in den nächsten Teilen der Serie, während wir unsere Reise zur Micro-Frontend-Migration fortsetzen und dabei weitere interessante und wertvolle Erkenntnisse gewinnen!

Ursprünglich veröffentlicht unter https://thesametech.com am 18. April 2023.

Sie können mir auch auf Twitter folgen und sich auf LinkedIn vernetzen , um Benachrichtigungen über neue Beiträge zu erhalten!