Wie Microfrontends funktionieren und wann man sie einsetzt

Formarse » Kostenlose Online-Kurse » Wie Microfrontends funktionieren und wann man sie einsetzt

Wenn Sie in der Webentwicklung arbeiten und Ihre Anwendung ständig wächst, ist es sehr wahrscheinlich, dass Das Frontend hat sich zu einem Monster entwickelt, das schwer zu warten ist.Endlose Builds, Teams, die sich mit dem Code überschneiden, und jede noch so kleine Änderung, die das Risiko birgt, die halbe Website lahmzulegen. In diesem Kontext ergeben sich folgende Entwicklungen: Mikrofrontends als Architektur, die entwickelt wurde, um diese riesige Schnittstelle aufzubrechen in besser handhabbare Teile, die sich unabhängig voneinander weiterentwickeln können.

In den letzten Jahrzehnten haben wir uns von nahezu statischen HTML-Seiten zu Umfangreiche und komplexe Webanwendungen, die mit Desktop-Software konkurrierenDiese Entwicklung hat viele Vorteile mit sich gebracht … aber auch neue Herausforderungen in Bezug auf Skalierbarkeit, Teamorganisation und Leistung. In diesem Artikel werden wir diese detailliert untersuchen. Wie Microfrontends funktionieren, warum sie entstanden sind, wann sich ihre Implementierung lohnt und welche Technologien für ihren Betrieb eingesetzt werden., indem man sich auf praktische Beispiele und auf bewährte Verfahren stützt, die sich in der Branche etabliert haben.

Was sind Microfrontends und woher kommen sie?

Der Begriff Microfrontends tauchten erstmals 2016 im ThoughtWorks Technology Radar auf....dasselbe Ökosystem, das Microservices populär gemacht hat. Die Idee ist einfach zu verstehen: Wenn wir gelernt haben, das Backend aufzuteilen in unabhängige Mikrodienste Um Skalierbarkeit und Flexibilität zu erreichen, warum nicht eine ähnliche Philosophie auf die Benutzeroberfläche anwenden?

In der klassischen Architektur ist das Frontend üblicherweise ein monolithische Anwendung, typischerweise eine riesige Single-Page-Anwendung Entwickelt mit React, Angular, Vue oder einer anderen Technologie. Im Laufe der Zeit sammelt diese Single-Page-Anwendung (SPA) Logik, Routen, Komponenten, Stile, globalen Zustand usw. an, bis zu dem Punkt, an dem Es ist sehr kostspielig, es weiterzuentwickeln, ohne etwas kaputt zu machen.Dies wird oft als „monolithisches Frontend“ bezeichnet.

Microfrontends schlagen vor, die Webanwendung als … zu betrachten. eine Reihe separater Funktionalitäten oder Geschäftsbereiche (zum Beispiel: Katalog, Kasse, Profil, Berichte) wobei Jede Domäne wird als eigenständige Frontend-Anwendung implementiert., wird von einem anderen Team betreut und anschließend visuell in ein einzigartiges Nutzererlebnis integriert.

Martin Fowler beschreibt es als „ein Architekturstil, bei dem mehrere unabhängige Frontends zu einem größeren Ganzen kombiniert werden“Es handelt sich um einen sehr ähnlichen Ansatz wie frühere Konzepte wie „in sich geschlossene Systeme“ oder „vertikale Systeme“, jedoch mit einem benutzerfreundlicheren Namen und ausgerichtet auf die moderne Welt des Webs.

In der Praxis bedeutet dies Folgendes Jedes Team ist funktionsübergreifend und trägt die Gesamtverantwortung. Auf ihrer Seite: von der Datenbank und dem Backend (Mikroservice) bis zum Mikrofrontend und der Benutzererfahrung, wodurch eine ständige Abhängigkeit von anderen Teams bei der Wertschöpfung vermieden wird.

Evolution der Webarchitekturen: vom Monolithen zum Microfrontend

Um vollständig zu verstehen, warum Microfrontends sinnvoll sind, ist es hilfreich, den Weg dorthin zu rekapitulieren: Das Web begann mit statischen Dokumenten, die miteinander verlinkt waren.Inhaltsorientiert, während Desktop-Anwendungen bereits über ausgereifte Architekturen (MVC, Schichten, Entwurfsmuster) verfügten, die für komplexe Software konzipiert waren.

Mit dem Aufkommen von JavaScript und der Verbesserung der Browser, Wir begannen damit, diesen Seiten Interaktivität hinzuzufügen.Dann kamen die modernen Frontend-Frameworks und das Konzept von Einzelseitenanwendung, wodurch ein Großteil der Logik im Browser konzentriert wird, um besonders reichhaltige und schnelle Nutzererlebnisse zu bieten.

Etwas Ähnliches geschah im Backend: Anfangs generierte der Server lediglich HTML aus den Daten, doch der wachsende Bedarf führte zur Einführung von komplexere Architekturen und schließlich Microserviceswobei jeder Dienst einen Teil der Geschäftsfunktionalität abdeckt und isoliert eingesetzt werden kann.

Das Paradoxe ist, dass Während das Backend in Microservices aufgeteilt wurde, blieb das Frontend ein einziger, riesiger Block. die diese Dienste in Anspruch nahmen. Daher die Idee: Wenn das Backend bereits aufgeteilt ist, macht es Sinn. eine ähnliche Aufteilung in der Schnittstelle widerspiegelnTeams nach Geschäftsbereichen statt nach technischen Ebenen ausrichten.

Wir können diese Entwicklung als einen Fortschritt visualisieren: Kompakter Monolith ohne klare Schichten → organisierter Monolith mit MVC → Microservices-Backend + monolithisches Frontend → Microservices-Backend + Frontend aufgeteilt in Microfrontendswobei jede vertikale Einheit den gesamten Stapel abdeckt.

Schlüsselideen und Designprinzipien bei Microfrontends

Über das allgemeine Konzept hinaus hat die Community, die mit Microfrontends gearbeitet hat, eine Reihe von Funktionen verfeinert. Prinzipien, die dazu beitragen, dass diese Architektur in der Praxis gut funktioniert und nicht zu Chaos führen:

• Vernünftiger Technologieagnostizismus: Jedes Team sollte seinen Technologie-Stack (React, Angular, Vue, Svelte, Web Components…) frei wählen können, ohne andere zu blockieren. Es empfiehlt sich jedoch, die Vielfalt einzuschränken, um eine „Framework-Anarchie“ zu vermeiden.
• Code- und Laufzeitisolation: Es wird empfohlen, Laufzeit- oder globale Zustände nur dann gemeinsam zu nutzen, wenn dies absolut notwendig ist. Jedes Microfrontend sollte autonom sein und nicht von globalen Variablen oder gemeinsam genutzten Einzelelementen abhängen.
• Präfixe und Namensräume pro Team: Verwenden Sie Namenskonventionen (z. B. CSS-Präfixe, Ereignisnamen, lokale Speicherschlüssel oder Cookies), um Kollisionen vermeiden und die Eigentumsverhältnisse jedes einzelnen Teils klar definieren..
• Setzen Sie auf Browser-APIs, anstatt eine eigene Infrastruktur zu entwickeln: Für die Kommunikation ist es vorzuziehen, DOM-Ereignisse und benutzerdefinierte Ereignisse statt komplexe globale Bussysteme oder selbstgebaute PubSubs zu entwerfen.
• Entwicklung robuster Schnittstellen: Funktionalität muss auch dann einen Mehrwert bieten, wenn JavaScript schlägt fehl oder benötigt sehr lange zum Laden.Techniken wie Single-Server-Rendering (SSR) und Progressive Enhancement werden oft kombiniert.

Wenn wir diese Prinzipien weise anwenden, Wir können mehrere Teams parallel arbeiten lassen, ohne dass diese sich gegenseitig behindern.unter Beibehaltung eines einheitlichen Nutzererlebnisses für den Endnutzer.

Wie Microfrontends aufgebaut sind: Das DOM als API und Custom Elements

Eine der leistungsstärksten Methoden zur Integration von Microfrontends in den Browser ist die Verwendung von Webkomponenten und insbesondere benutzerdefinierte ElementeDie Idee besteht darin, dass jedes Team seine Funktionalität unter einem individuell gestalteten Label des jeweiligen Stils verpackt. <blue-buy sku="t_porsche"></blue-buy>.

In diesem Modell ist die DOM fungiert als öffentlicher Vertrag zwischen TeamsDie „API“ dieser Komponente ist keine Klasse oder TypeScript-Schnittstelle, sondern die Spezifikation ihres Tags selbst: Elementname, unterstützte Attribute und ausgelöste EreignisseJedes andere Team kann die Komponente verwenden, ohne deren interne Implementierung zu kennen, solange es diesen Vertrag einhält.

Wenn der Browser auf ein benutzerdefiniertes Element stößt, führt er die Methode aus. connectedCallback() der Klasse, die es definiertAb diesem Zeitpunkt verhält es sich wie ein Standardelement mit seinen Eigenschaften, Methoden und Ereignissen. Wir können es auch implementieren attributeChangedCallback() auf Veränderungen bestimmter Eigenschaften reagieren.

Die gebräuchlichste Konvention ist, dass Der Name des benutzerdefinierten Elements enthält einen Bindestrich. um die Kompatibilität mit zukünftigen HTML-Spezifikationen zu gewährleisten, zum Beispiel <order-minicart> o <blue-buy>Darüber hinaus ist es üblich, die Teampräfix als Teil des Namens Kollisionen vermeiden und Verantwortlichkeiten klären, indem man sich das DOM ansieht.

Heute Alle gängigen Frontend-Frameworks unterstützen Web Components.Sie können ein Custom Element in React, Angular, Vue, Svelte oder Preact einbetten, als wäre es nur ein weiteres HTML-Tag, und viele ermöglichen es Ihnen, Ihre Anwendung als wiederverwendbare Webkomponente zu verpacken.

Client-Server-Integration und serverseitiges Rendering (SSR)

Das Rendern von Microfrontends ausschließlich auf Clientseite kann folgende Folgen haben: Leere Bildschirme während des Wartens auf JavaScriptDies ist katastrophal für die wahrgenommene Leistung und Stabilität, falls beim Laden der Pakete ein Fehler auftritt. Daher kombinieren viele Implementierungen Benutzerdefinierte Elemente im Browser mithilfe serverseitiger SSR-Techniken.

Ein sehr interessantes Muster ist, dass Jedes Team stellt auf seinem Server einen Endpunkt bereit, der den HTML-Code seines Fragments zurückgibt. (was intern das Ergebnis ihrer Methode sein könnte) render()Anschließend bindet der Hauptwebserver (z. B. Nginx) die Seite ein. Server Side Includes (SSI) oder Varianten wie ESIwobei jedes HTML-Fragment in die Antwort eingefügt wird, bevor diese an den Browser gesendet wird.

So erreicht man etwas Ähnliches wie ein „universelle Webkomponente": Dasselbe Fragment kann serverseitig über SSI gerendert werden und, sobald das JavaScript auf dem Client geladen ist, rehydrieren oder diesen Inhalt schrittweise verbessern ohne dass der Benutzer eine plötzliche Veränderung bemerkt.

Der Nachteil dieses Ansatzes ist, dass Die Seitenladezeit wird durch das langsamste Microfrontend beeinflusst.Deshalb ist es üblich, teure Fragmente zwischenzuspeichern und in manchen Fällen bestimmte Blöcke nicht in das anfängliche SSR aufzunehmen, sondern sie gegebenenfalls asynchron im Browser zu laden.

Ein typisches Beispiel ist ein Abschnitt von personalisierte EmpfehlungenWir können zunächst einen leeren Raum bedienen oder, noch besser, einen Skelett Ganz einfach: Speicherplatz reservieren und lästige Reflows vermeiden, und ihn dann mit dem endgültigen Inhalt füllen, sobald das entsprechende Microfrontend die Daten erhalten hat.

Kommunikation zwischen Microfrontends und State-Management

In einer Architektur mit vielen Microfrontends ist einer der kritischen Punkte die Entscheidung wie sie miteinander kommunizieren und wie sie einen gemeinsamen Zustand verwaltenFalls es eine gibt. Hierbei kommen üblicherweise mehrere sich ergänzende Strategien zum Einsatz:

• DOM-Attribute und -Eigenschaften: Bei Vater-Sohn-Beziehungen genügt es oft, Attribute eines benutzerdefinierten Elements aktualisieren (zum Beispiel, sku (in einem „Kaufen“-Button). Das Element reagiert auf diese Änderungen und wird neu gerendert.
• DOM-Ereignisse (CustomEvent): Für stärker entkoppelte Benachrichtigungen (z. B. „Ein Produkt wurde dem Warenkorb hinzugefügt“) werden solche erstellt. Personalisierte Events, die ein sprudelndes Erlebnis schaffen über den DOM-Baum und kann von jeder interessierten Komponente erfasst werden.
• Sehr gut gekapselte globale APIs: In manchen Fällen kann es sinnvoll sein, offenzulegen imperative Methoden in DOM-Elementen (Wie z refresh() in einem Mini-Korb) oder einem kleinen gemeinsam genutzten SDK, solange die Isolation nicht verletzt wird.
• Zustandsverwaltung über Microfrontend: Jedes Microfrontend hat üblicherweise Ihr eigener Laden (Redux, NgRx, Zustand, MobX usw.) für seinen internen Zustand, wodurch ein großer globaler Zustand vermieden wird, der Teams zu einer ständigen Koordination zwingt.

Es ist ratsam, dies so weit wie möglich zu vermeiden. massive globale Staaten oder Bibliotheken zur gemeinsamen Staatsverwaltung das führt zu einer übermäßigen Kopplung von Microfrontends. Wenn zwei oder mehr Module ständig Daten austauschen müssen, ist es wahrscheinlich, dass in der Realität Sie müssen Teil derselben Domäne sein und ein einzelnes Microfrontend darstellen. statt mehrerer.

Teamorganisation: Branchen und Geschäftsbereiche

Einer der größten Vorteile von Microfrontends ist nicht nur technischer, sondern auch organisatorischer Natur: Es ermöglicht die Strukturierung von Teams nach Geschäftsfunktionen anstatt nach technischen Ebenen.Dieses Muster wird oft als „vertikale Organisation“ bezeichnet.

Stellen Sie sich einen Online-Schuhshop vor. Anstatt ein „Frontend-Team“, ein „Backend-Team“ und ein „Datenbank-Team“ zu haben, könnten Sie Folgendes einrichten: Teams, die sich auf Bereiche wie Suche und Filter, Produktlisten, Warenkorb und Kasse, Benutzerkonto usw. konzentrieren.

Jedes Team ist für sein/ihr Microfrontend (oder seine Microfrontends) und die zugehörigen Backend-Dienste verantwortlich. Dies ermöglicht es ihnen, Treffen Sie schnelle Entscheidungen, arbeiten Sie selbstständig und übernehmen Sie die Verantwortung für die Ergebnisse von Anfang bis Ende.ohne jeden einzelnen Tag auf andere Gruppen angewiesen zu sein.

In einem typischen Machbarkeitsnachweis, Shop-Homepage kann enthalten:

• Ein Microfrontend für die Suche und Filterung von Hausschuhen.
• Ein weiteres Microfrontend für die Ergebnisliste.
• Ein drittes für die Einkaufswagen.
• Und ein Container-Microfrontend (Host), das orchestriert und integriert visuell das oben Genannte.

Aus Nutzersicht sieht alles wie eine einzige Seite aus. Intern hat jedoch jeder Block Folgendes: Ihr Repository, Ihre CI/CD-Pipeline und Ihr Release-ZyklusDadurch werden Reibungsverluste reduziert und häufige und klar definierte Lieferungen gefördert.

Vorteile der Microfrontend-Architektur

Die Implementierung von Microfrontends in großen Projekten kann viele Vorteile mit sich bringen, sofern sie gut durchdacht erfolgt. Zu den wichtigsten gehören:

• Autonome Teams und unabhängige Einsätze: Jedes Microfrontend kann sein Entwickelt, getestet und bereitgestellt, ohne den Rest der Anwendung zu beeinträchtigen.Falls im Warenkorb ein Fehler auftritt, wird dieser behoben und nur der betreffende Artikel angezeigt.
• Verbesserte technische und organisatorische Skalierbarkeit: Der Code ist in überschaubare Module unterteilt und die Teams wachsen nach Geschäftsbereichen. effektivere Verteilung der Arbeitslast.
• Geringere Risiken bei Änderungen und Releases: weil der Code besser isoliert ist Fehler sind tendenziell begrenzt auf eine bestimmte Domain beschränkt und es ist weniger wahrscheinlich, dass eine einfache Änderung die gesamte Website lahmlegt.
• Potenziell verbesserte Leistung: Bei sorgfältiger Planung kann es Laden Sie von jedem Mikrofrontend nur das Nötigste. (Code-Splitting, Lazy Loading), wodurch die anfängliche Größe der Anwendung reduziert wird.
• Einfaches Testen und Warten: Das Testen eines isolierten Microfrontends ist einfacher als das Testen einer riesigen Single-Page-Anwendung. wobei jede Interaktion mehrere Teile berührt.
• Möglichkeit der Kombination von Technologien, wenn unvermeidbar: Obwohl eine übermäßige Nutzung nicht empfehlenswert ist, ermöglichen Microfrontends Folgendes: neue Frameworks einführen oder schrittweise von einem alten migrieren ohne alles auf einmal neu schreiben zu müssen.

Nachteile, Risiken und wann man Microfrontends NICHT verwenden sollte

Es gibt nicht nur Vorteile. Microfrontends haben auch ihre Nachteile und Sie fügen unnötige Komplexität hinzu, wenn sie dort eingesetzt werden, wo sie nicht benötigt werden.Zu den wichtigsten Nachteilen gehören:

• Höhere architektonische und betriebliche Komplexität: sie werden gebraucht Mehr Repositories, mehr Pipelines, mehr Umgebungen, mehr KoordinationDie Kosten für Infrastruktur und Orchestrierung steigen.
• Kompliziertere Zustandsverwaltung: wenn mehrere Parteien Informationen austauschen müssen, Die Koordinierung des Weltstaats kann heikel sein. und erfordert eine sorgfältige Planung.
• Risiken visueller und UX-Inkonsistenz: Wenn jedes Team seinen eigenen Weg geht, erhält man am Ende ein visueller Frankenstein wobei jeder Bereich der App scheinbar zu einem anderen Unternehmen gehört.
• Erhöhte Größe der Datenpakete und HTTP-Anfragen: wenn jedes Microfrontend seine eigenen Abhängigkeiten mit sich bringt, Das Gesamtgewicht kann sprunghaft ansteigen. und die Leistung verschlechtern.
• Höhere Anfangslast: abhängig von der Strategie, Das Laden mehrerer Microfrontends kann die Zeit verlängern, bis der Benutzer etwas Nützliches sieht..
• Lernkurve: Die Teams müssen neue Arbeitsweisen kennenlernen, Werkzeuge (wie Module Federation, Single-SPA usw.) und Integrationsmuster.

Für all das ist es wichtig Microfrontends sollten in keinem Projekt verwendet werden.Bei kleineren Anwendungen (ein Blog, eine einfache Unternehmenswebsite, ein Portfolio, Machbarkeitsstudien mit geringem Umfang) ist es in der Regel ausreichend, gute Komponentenbildung innerhalb eines einzigen FrontendsMikrofrontends für folgende Fälle reservieren:

• Die Anwendung ist groß oder wird stark wachsen. und es wird mit einer deutlichen Steigerung der Funktionalität und des Datenverkehrs gerechnet.
• Viele Entwickler sind beteiligt, verteilt auf mehrere Teams. die parallel arbeiten müssen, ohne sich ständig gegenseitig ins Knie zu schießen.
• Teile der Anwendung müssen sehr häufig bereitgestellt werden.Risikominimierung bei jeder Veröffentlichung.
• In einem monolithischen Frontend werden klare Engpässe erkannt. das organisatorisch bereits zu klein geworden ist.

Technologien und Ansätze zur Implementierung von Microfrontends

Es gibt verschiedene gängige Strategien und Werkzeuge zum Aufbau einer Microfrontend-Architektur. Die heute am weitesten verbreiteten sind:

• Modulföderation (Webpack 5, Vite usw.): ermöglicht Gemeinsame Module zwischen unabhängigen Anwendungen zur Laufzeit. Es eignet sich ideal für einen "Host", um entfernte Microfrontends zu laden, die selbst mit unterschiedlichen Frameworks geschrieben wurden.
• Single-Spa und Derivate (wie z. B. Qiankun): ein Rahmenwerk, das für Mehrere Single-Page-Anwendungen in einer einzigen App zusammenführenVerwaltung des Routings und des Lebenszyklus jeder Teilanwendung.
• Webkomponenten: basierend auf Standards wie Benutzerdefinierte Elemente, Shadow DOM und HTML-VorlagenSie eignen sich perfekt, um wiederverwendbare Komponenten zu kapseln und Stile und Verhaltensweisen zu isolieren.
• SSI/ESI/Tailor/Compoxure: Techniken von HTML-Fragment-Serverzusammensetzung Von verschiedenen Diensten generiert, nützlich für SSR und für stark inhaltsorientierte Apps.
• iFrames: eine sehr isolierte Lösung, die manchmal zur Integration älterer Anwendungen nützlich ist, aber mit erhebliche Einschränkungen in Bezug auf UX und Kommunikation.
• BFF (Backend für Frontend): Obwohl es selbst keine Microfrontend-Technik ist, tritt sie häufig in Verbindung mit ihnen auf: Jedes Frontend oder Microfrontend verfügt über ein individuelles Backend. Das liefert ihm genau die Daten, die er benötigt.

Im modernen JavaScript-Ökosystem Die Modulföderation hat sich zu einer der Säulen entwickelt. robuster. Mit Webpack 5 (und auch mit Vite über Plugins) ist es in jeder Anwendung definiert:

• Welche Module sind sie als abgelegen bezeichnen (zum Beispiel das Warenkorb-Mikrofrontend, das Angebots-Mikrofrontend usw.).
• Welche Module Sie werden aus anderen Quellen bezogen (zum Beispiel der Host, der diese Microfrontends importiert).
• Welche Abhängigkeiten bestehen? teilen (React, Angular, gängige Bibliotheken usw.), um Duplikate zu vermeiden.

Das Ergebnis ist, dass Der Host kann Remote-Komponenten dynamisch importieren. Als wären sie lokale Module, aber in Wirklichkeit werden sie von anderen Anwendungen bedient, die auf anderen Servern und Ports bereitgestellt sind.

Microfrontends mit React, Angular und Next.js

Im Bereich der spezifischen Rahmenwerke gibt es mehrere Muster, die bereits recht ausgereift sind um mit Microfrontends zu arbeiten:

Mit ReagierenDie Kombination aus Modulföderation und dem Bibliotheksökosystem (Router, Speicher usw.) macht es Es ist sehr praktisch, unabhängige Microfrontends zu erstellen.React ermöglicht effizientes Rendering und die Versionsmigration ist in der Regel einfacher als bei anderen Frameworks, was dazu beiträgt, dass sich jedes Microfrontend in seinem eigenen Tempo weiterentwickeln kann.

Die größte Herausforderung bei React mit Microfrontends besteht darin, dass jedes Modul seine eigene Kopie von React und den dazugehörigen Abhängigkeiten mit sich führt. Das Entladegewicht kann sich drastisch erhöhen und die Ladezeiten beeinflussen.Deshalb ist es wichtig, gemeinsam genutzte Abhängigkeiten richtig zu konfigurieren und Lazy-Loading-Techniken anzuwenden.

Mit AngularDas Tool selbst und seine Architektur passen sehr gut zusammen: Angular organisiert Projekte in Arbeitsbereiche, Projekte und BuchhandlungenDies spiegelt sich sehr gut in einem Monorepo wider, das mehrere Microfrontends enthält. Seit Angular 12 ist dies integriert. Modulföderation Webpack 5 und Tools wie Nx erleichtern die Orchestrierung.

In diesem Kontext ermöglichen gemeinsam genutzte Bibliotheken Komponenten und Hilfsprogramme in verschiedenen Microfrontends wiederverwenden ohne Code-Duplizierung. Muster wie die hexagonale Architektur werden ebenfalls häufig innerhalb jedes Microfrontends verwendet, zusammen mit NgRx für das Zustandsmanagementwas die langfristige Wartungsfreundlichkeit begünstigt.

Bei Next.jsDas React-Framework für die Produktion; die Idee besteht darin, sein Modell zu nutzen Hybrid-Rendering (SSR und SSG) gemeinsam mit der Modulföderation aufbauen Mikrofrontends, die in eine „Host“-Next-App integriert sindNext 10.2 und spätere Versionen unterstützen Webpack 5 standardmäßig, in früheren Versionen konnten externe Pakete zur Integration verwendet werden.

Dieser Ansatz ist sehr interessant, wenn man möchte dass jeder Abschnitt oder jede Gruppe von Seiten Ihrer Next-Website ein unabhängiges Microfrontend istDies ermöglicht es verschiedenen Teams, Funktionen bereitzustellen, ohne den Rest des Systems zu beeinträchtigen.

Bewährte Vorgehensweisen für die Arbeit mit Microfrontends

Um das Beste daraus zu machen, ohne dabei umzukommen, empfiehlt es sich, eine Reihe von Schritten zu befolgen bewährte Praktiken, die sich in der Branche etabliert haben:

• Einschränkung der technologischen Vielfalt: Auch wenn es verlockend ist, jedem Team die Wahl des Frameworks zu überlassen, In der Praxis lohnt es sich, den Hauptstapel auszurichten. (zum Beispiel alles in React oder alles in Angular) und Ausnahmen nur für wirklich gerechtfertigte Fälle vorsehen.
• Vermeiden Sie eine übermäßige Fragmentierung der Anwendung: Wenn Microfrontends zu klein gestaltet werden, führt das zu einem Überschuss an Bauteilen ohne wirklichen Wert Dies führt bereits zu einer enormen Komplexität bei der Koordination. Ein gutes Kriterium ist, dass jedes Microfrontend Folgendes abdecken sollte: ein klarer und unmissverständlicher Geschäftszweck.
• Definiere klare Verträge zwischen den Teams: Es ist unerlässlich, zuzustimmen. wie die APIs kommunizieren, welche Ereignisse jedes Modul auslöst, welche Attribute es unterstützt jede Komponente usw. und dokumentieren Sie diese gut.
• Architektur an Organisation anpassen: Es ist nicht sehr sinnvoll, Microfrontends zu haben, wenn dann Das Geschäft erfordert die gleichzeitige Bereitstellung aller Komponenten.Wenn das Unternehmen in seinen Prozessen „monolithisch“ bleibt, wird die Architektur nicht viel beitragen.
• Denken Sie von Anfang an an die Leistung: Code-Splitting, Lazy Loading und Caching nutzen, um Die Anfangslast darf nicht bestraft werden.und Skelette verwenden, um die Benutzerwahrnehmung bei Teillasten zu verbessern.
• Visuelle und UX-Konsistenz wahren: anlehnen ein gemeinsames Designsystem oder eine gemeinsame Komponentenbibliothek (auch als frameworkneutrale Webkomponenten), um zu verhindern, dass jedes Microfrontend so aussieht, als gehöre es zu einem anderen Produkt.
• Konzentriere dich nicht obsessiv auf die Wiederverwendung zwischen Microfrontends: Der Versuch, alles wiederverwendbar zu machen, kann dazu führen, dass die Bereitstellung wird dadurch komplizierter und die Abhängigkeiten zwischen den Teams nehmen zu.Die meisten Microfrontends repräsentieren sehr spezifische Domänen, die nicht wortwörtlich auf andere Seiten kopiert werden.
• Test auf verschiedenen Ebenen: zusätzlich zu den Unit-Tests für jedes Microfrontend, Integrations- und End-to-End-Tests sind erforderlich. die überprüfen, wie sie sich auf dem Host zusammen verhalten.

Wann und wie man mit Microfrontends beginnt

Wenn Sie mit dem Gedanken spielen, den Schritt zu wagen, ist das Klügste, was Sie tun können, Beginnen Sie mit einem spezifischen und klar definierten Teil Ihrer Bewerbung.Anstatt alles auf einmal neu zu schreiben, könnten Sie beispielsweise den Checkout-Bereich oder das Administrationsmodul in ein Microfrontend umwandeln und in der Praxis sehen, ob die Architektur zu Ihrem Workflow passt.

Auf der lokalen Entwicklungsebene ist es oft sinnvoll, Werkzeuge zu standardisieren: Node und Framework in aufeinander abgestimmten Versionen, ein gemeinsamer Projektarchetyp oder eine Vorlage (zum Beispiel ein Unternehmensarchetyp für Webanwendungen mit MFE-Option) und konsistente Startskripte für alle Microfrontends.

Hinsichtlich der Bereitstellung empfiehlt es sich, die Abstimmung mit den Infrastruktur- oder Betriebsteams vorzunehmen. um geeignete Umgebungen zu schaffen, in denen jedes Microfrontend über eine eigene Pipeline verfügt.und wo der Host Remote-Anwendungen sicher und versionsspezifisch laden kann. In vielen Organisationen beinhaltet dies die Integration in Prozesse wie beispielsweise DevSecOps und Pre-Cloud- oder Cloud-Plattformen.

Innerhalb jedes Microfrontends gibt es interne Muster wie zum Beispiel hexagonale Architektur, eigenständige Komponenten, Zustandsverwaltung mit NgRx, Redux oder ähnlichem sowie Unit-Tests mit gängigen Frameworks (Jasmine, Karma, Jest…). All dies trägt dazu bei, dass auch bei einer komplexen Gesamtanwendung, Jedes einzelne Teil wird sauber und ordentlich gehalten..

Darüber hinaus die übergreifenden Komponenten (zum Beispiel, Kopfzeilen, Navigationsleisten oder gängige Widgets) können als eigenständige Webkomponenten (auch solche, die mit Vue oder einem anderen Framework erstellt wurden) bereitgestellt werden für visuelle Konsistenz über alle Microfrontends hinweg sicherstellen ohne sie an den jeweiligen Stapel zu binden.

Microfrontends bieten eine leistungsstarke Möglichkeit, Zähmen Sie riesige Frontends, indem Sie sie in autonome, auf das Geschäft abgestimmte Module unterteilen.Allerdings erfordern sie Disziplin, Teamvereinbarungen und eine solide technische und organisatorische Grundlage; bei umsichtiger Anwendung können sie ein wirksames Instrument zur Skalierung von Produkten und Teams sein, werden sie aber nur deshalb eingesetzt, weil es im Trend liegt oder ohne wirklichen Bedarf, so werden sie leicht zu unnötigem Over-Engineering und einem ständigen Problem.