Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Verwaltung von Abhängigkeiten aus bereichsübergreifenden Gründen

Ein bewusstes Abhängigkeitsmanagement ist entscheidend für den Erfolg einer verteilten Architektur wie Mikro-Frontends. Das Abhängigkeitsmanagement ist einer der schwierigsten Bereiche der Mikro-Frontend-Entwicklung.

In einer Micro-Frontend-Architektur sind zwei wichtige Aspekte des Abhängigkeitsmanagements die Leistungseinbußen, die durch die Übertragung großer Codeartefakte auf den Client entstehen, und der Overhead an Rechenressourcen. Im Idealfall muss Ihr Unternehmen festlegen, wie Abhängigkeiten in einer verteilten Frontend-Architektur aufrechterhalten werden.

Drei praktikable Strategien, um die Aufrechterhaltung von Abhängigkeiten vorzuschreiben, sind „Share Nothing“ und verwenden Webstandards wie Importzuordnungen und Modulverbund. Andere Ansätze sind gegen Pattern gerichtet, weil sie gegen die Grundprinzipien verteilter Architekturen verstoßen.

Teilen Sie nichts, wo immer möglich

Der Share-Nothing-Ansatz postuliert, dass Abhängigkeiten zwischen unabhängigen Softwareartefakten überhaupt nicht gemeinsam genutzt werden sollten, zumindest nicht bei der Integration oder Laufzeit. Das heißt, wenn zwei Mikro-Frontends von derselben Bibliothek abhängen, muss jedes zum Zeitpunkt der Erstellung in der Bibliothek gebacken und separat ausgeliefert werden. Außerdem muss jedes Mikro-Frontend sicherstellen, dass die Bibliothek globale Namespaces und gemeinsam genutzte Ressourcen nicht verschmutzt.

Dies führt zu Redundanzen, ist aber ein bewusster Kompromiss mit maximaler Agilität. Da es keine gemeinsamen Laufzeitabhängigkeiten gibt, haben Teams maximale Flexibilität, um die Software so weiterzuentwickeln, wie sie es für sinnvoll halten, solange sie dies im Rahmen ihrer Lösung tun und keine Schnittstellenverträge verletzen.

Auf einer Plattform, auf der Mikrofrontends dem Share-Nothing-Prinzip folgen, ist es wichtig, Mikro-Frontends so leicht wie möglich zu halten. Es erfordert Entwickler, die ihre Mikrofrontends kompetent und gewissenhaft im Hinblick auf die Leistung optimieren und die Benutzererfahrung nicht der Entwicklererfahrung opfern.

Wenn du Code teilst

Wenn Sie sich entscheiden, Code gemeinsam zu nutzen, können Sie ihn als Bibliotheken oder Laufzeitmodule teilen. Das Frontend-Kernteam stellt beispielsweise Bibliotheken für die Nutzung im Mikro-Frontend über CDNs bereit. Die Business Value Teams können die Bibliotheken zur Laufzeit laden oder sie können Paket-Repositorys verwenden, um ihre Bibliotheken zu veröffentlichen. Micro-Frontend-Teams können zum Zeitpunkt der Erstellung anhand einer bestimmten Version der Paketbibliothek entwickeln, ähnlich wie mobile Anwendungen, die hybride Frameworks verwenden.

Eine dritte Option ist die Verwendung einer privaten Paketregistrierung, um die Integration gängiger Bibliotheken während der Erstellung zu unterstützen. Dadurch wird das Risiko verringert, dass eine grundlegende Änderung im Bibliotheksvertrag Fehler zur Laufzeit auslöst. Dieser konservativere Ansatz erfordert jedoch mehr Governance, um alle Mikrofrontends mit neueren Bibliotheksversionen zu synchronisieren.

Um die Ladezeiten der Seiten zu verbessern, können Mikrofrontends die Bibliotheksabhängigkeiten externalisieren, sodass sie aus zwischengespeicherten Chunks von einem CDN wie Amazon geladen werden. CloudFront

Um Laufzeitabhängigkeiten zu verwalten, können Mikrofrontends Import-Maps (oder Bibliotheken wieSystem.js) verwenden, um anzugeben, von wo jedes Modul zur Laufzeit geladen wird. Webpack Module Federation ist ein weiterer Ansatz, um auf eine gehostete Version eines Remote-Moduls zu verweisen und gemeinsame Abhängigkeiten zwischen unabhängigen Mikrofrontends aufzulösen.

Ein anderer Ansatz besteht darin, das dynamische Laden von Import-Maps mit einer ersten Anfrage an einen Discovery-Endpunkt zu erleichtern.

Gemeinsamer Status

Um die Kopplung von Mikrofrontends zu reduzieren, ist es wichtig, ein globales State-Management zu vermeiden, auf das alle Mikrofrontends in derselben Ansicht zugreifen können, ähnlich wie bei monolithischen Architekturen. Ein globaler Redux-Store, auf den beispielsweise von allen Mikrofrontends aus zugegriffen werden kann, erhöht die Kopplung.

Ein Muster zur Eliminierung des gemeinsamen Zustands besteht darin, ihn in Mikro-Frontends einzukapseln und mit asynchronen Nachrichten zu kommunizieren, wie bereits beschrieben.

Wenn es absolut notwendig ist, führen Sie klar definierte Schnittstellen für den globalen Status ein und entscheiden Sie sich für die gemeinsame Nutzung nur zum Lesen, um unerwartetes Verhalten zu vermeiden:

Wenn Sie mehrere Informationen über Mikro-Frontends hinweg gemeinsam nutzen müssen, empfehlen wir, die Grenzen der Mikro-Frontends erneut zu überprüfen. Die Notwendigkeit des Austauschs könnte auf die Geschäftsentwicklung oder ein unterdurchschnittliches anfängliches Design zurückzuführen sein.

Es ist auch möglich, serverseitige Sitzungen zu verwenden, bei denen jedes Mikro-Frontend die erforderlichen Daten mithilfe einer Sitzungs-ID abruft. Um die Kopplung zu reduzieren, ist es wichtig, den gemeinsamen Status zu eliminieren und die spezifischen Sitzungsdaten für das Mikrofrontend getrennt zu halten.