Inhaltsverzeichnis[Ausblenden][Zeigen]
Die Idee der Microservices hat in letzter Zeit viel Aufmerksamkeit erregt, und viele Unternehmen nutzen sie, um große, monolithische Backends abzuschaffen.
Den gleichen Weg mit dem Frontend zu gehen, ist für viele Unternehmen immer noch eine Herausforderung, auch wenn diese verteilte Art des serverseitigen Aufbaus von Web-Apps in Bezug auf Recherche und Ausführung mehr oder weniger zuverlässig ist.
Aufgrund seiner engen Abhängigkeit macht es der clientseitige Monolith normalerweise schwierig, neue Funktionen zu integrieren, neue Technologien zu übernehmen und einzelne Komponenten zu skalieren.
Diese und andere Herausforderungen haben Frontend-Entwickler dazu veranlasst, die Verwendung von Microservices zu untersuchen.
Als Ergebnis wurde eine brandneue Architekturstrategie namens Micro Frontend entwickelt, um die Front-End-Schicht von Websites und webbasierten Anwendungen zu erstellen.
Der Begriff tauchte erstmals 2016 auf und sorgt seither für viel Aufmerksamkeit für den guten Zweck.
Dieser Artikel vermittelt ein allgemeines Verständnis darüber, was Mikro-Frontends sind und welche Probleme sie ansprechen. Es funktioniert, sowie Vor- und Nachteile.
Einführung in die Mikro-Frontend-Architektur
Eine zeitgemäße Methode der Frontend-Entwicklung namens Mikro-Frontend-Architektur teilt a Web-Anwendung in kleine, unabhängige Teile.
Für den Endverbraucher erscheinen diese Teile als eine Einheit, auch wenn sie unabhängig voneinander konstruiert und dann zusammengefügt wurden.
Mit dem Unterschied, dass Micro-Frontends die Client-Seite und nicht die Server-Seite von Online-Lösungen betreffen, ist die ihnen zugrunde liegende Logik identisch mit der von Microservices.
Die Herstellung anspruchsvoller webbasierter Produkte ist am sinnvollsten, wenn ein Micro-Frontend-Ansatz verwendet wird.
Mikro-Frontends ermöglichen es vielen Teams im Gegensatz zu einem konventionelleren Frontend-Monolithen, separat an verschiedenen Softwareprojekten zusammenzuarbeiten.
Programmierer können mit diesem Architekturdesign Web-Apps schneller und mit größerer Skalierbarkeit und Wartbarkeit erstellen.
Einfach ausgedrückt ist jedes Mikro-Frontend nur ein Stück Code für eine bestimmte Komponente der Webseite.
Diese Funktionen werden von separaten Teams gesteuert, die jeweils auf eine bestimmte Branche oder ein bestimmtes Ziel spezialisiert sind.
Monolithische vs. Microservices vs. Micro-Frontend-Architektur
Denken Sie an einen Umzug. Wird es für Sie einfacher sein, alles in einer Reihe kleiner, fachmännisch beschrifteter Kartons zu organisieren und einzeln umzuziehen oder das gesamte Personal in einen riesigen Karton zu packen und an einen neuen Ort zu transportieren?
Die offensichtliche Lösung ist da.
Diese Analogie vergleicht die zwei unterschiedlichen Webanwendungsarchitekturen, Monolithen und Microservices (auch bekannt als Micro-Frontends).
Monolithische Architektur
Vielleicht können Sie sich an die „gute alte Zeit“ erinnern, als eine vollständige Anwendung als einzelne, zusammenhängende Einheit erstellt wurde. Eine solche Methode wird als Monolith bezeichnet, was ein alter Begriff für einen großen Steinblock ist.
Das macht Sinn.
Monolithische Systeme haben voneinander abhängige Elemente. Wenn Sie also etwas ändern oder eine neue Funktion hinzufügen möchten, ist es möglich, dass das gesamte System kaputt geht.
Obwohl es veraltet ist, existiert es gelegentlich noch. Ja, wir kennen Ihren aktuellen Ausdruck.
Die konzeptionelle Aufteilung der Codebasis in zwei verschiedene Komponenten – Frontend (clientseitig) und Backend (serverseitig) – wurde unvermeidlich, als neue Technologien entwickelt und Softwareprodukte komplizierter wurden.
Die beliebteste Arbeitsweise ist heute die Trennung zwischen der Präsentationsschicht, mit der ein Endbenutzer interagiert, und allem, was im Hintergrund passiert.
Es werden zwei Softwareentwicklungsteams benötigt, wobei das Front-End-Team die visuellen Komponenten erstellt und das Back-End-Team die Webdienste, Geschäftslogik, Datenzugriff, Integrationen usw. erstellt.
Trotz dieser Trennung bleibt diese Strategie jedoch von Natur aus monolithisch.
Die wichtigste Änderung besteht darin, dass wir jetzt zwei große Codeblöcke haben – das Frontend und das Backend – statt einer riesigen Anwendung. Monolithische Architekturen müssen nicht schrecklich sein; Sie haben ein paar Vorteile, einschließlich
- Einfache und schnelle Entwicklung für winzige Anwendungen mit einer Codebasis aus einer einzigen Quelle und einem sehr einfachen Design;
- Das Testen und Debuggen ist sehr unkompliziert, da sich der gesamte Code an einem Ort befindet, was es für ein Team einfacher macht, den Ablauf einer Anfrage zu verfolgen und Fehler zu identifizieren.
- Schon früh in der Entwicklung einer Anwendung sind die Aufwände günstiger, da weder Infrastrukturkosten noch Entwicklungskosten anfallen, bis neue Features hinzugefügt werden.
Die Nachteile dieser Strategie spiegeln sich in wider
- Eingeschränkte Bereitstellungsflexibilität – Teams müssen warten, wenn nur eine Handvoll von ihnen an dem Projekt arbeiten und jedes Mal, wenn Sie den Code aktualisieren, eine neue Bereitstellung erforderlich ist;
- Die Einführung neuer Technologien ist eine Herausforderung, da dazu ein erheblicher Teil, wenn nicht das gesamte Projekt neu geschrieben werden muss.
- Wenn die Anzahl der Entwickler zunimmt, wird ein Codesystem eng miteinander verbunden, kompliziert und schwer zu verwalten und zu verstehen.
- Organisatorische Probleme – jedes Teammitglied muss dieselbe Version von Bibliotheken verwenden und alle Änderungen melden, wenn viele Teams an einem monolithischen Projekt arbeiten.
- Bedenken hinsichtlich der Skalierbarkeit – da die Komponenten des Projekts miteinander verbunden sind, stellt eine separate Skalierung Schwierigkeiten dar, die zu erheblichen Ausfallzeiten und höheren Ausgaben führen.
- Die komplexe Logik des Projekts könnte für neue Teammitglieder schwer zu verstehen sein, insbesondere wenn die Ingenieure, die ursprünglich daran gearbeitet haben, nicht mehr beschäftigt sind.
Die Entwicklung von Microservices und ihren nahen Verwandten sowie Micro-Frontends befasste sich mit den Hauptproblemen monolithischer Systeme.
Microservices-Architektur
Die als Microservices bekannte Architekturmethode ermöglicht die Erstellung vieler lose verbundener und unabhängig einsetzbarer kleinerer Komponenten oder Dienste, die ein Anwendungs-Backend bilden.
Jeder Dienst hat seine eigene Codebasis, CI/CD-Pipelines, DevOps-Prozeduren und Prozesse für deren Ausführung.
Sie können sehen, dass das monolithische Backend-Team in separate Teams unterteilt ist, indem Sie sich das obige Bild ansehen.
Jeder konzentriert sich einzeln auf einen anderen Aspekt der Anwendung (z. B. Produktdienst, Suchdienst und Zahlungsdienst).
Die Kommunikation zwischen den Diensten erfolgt über etablierte Protokolle, die als APIs bekannt sind, wie z. B. das leichtgewichtige REST-API-Protokoll, das synchrone Anfrage-Antwort-Muster verwendet.
Eine weitere Option ist die asynchrone Kommunikation mit Software wie Kafka, die Publish/Subscribe-Kommunikationsstrukturen und -Ereignisse bietet.
Microservices lassen sich über ein Backend für den Frontend-Dienst (BFF) oder ein API-Gateway über das Netzwerk in das Frontend integrieren. BFF bietet eine angepasste API für jeden Client, während API-Gateways einen einzigen Zugangspunkt für eine Sammlung von Microservices bieten.
Aber selbst mit autonomen Backend-Komponenten und all den Vorteilen, die sie bieten, ist das Frontend immer noch ein Monolith.
Daher sind hier Mikro-Frontends nützlich.
Micro-Frontend-Architektur
Ähnlich wie bei Microservices, wo lose verknüpfte Komponenten von mehreren Teams verwaltet werden, überträgt die Micro-Frontend-Architektur das Konzept auf den Browser.
Diese Benutzeroberflächen von Webanwendungen folgen dieser Struktur, die aus weitgehend autonomen Komponenten besteht.
Teams werden auch eher nach Kundenbedürfnissen oder Anwendungsfällen als nach bestimmten Fachkenntnissen oder Technologien zusammengestellt.
Folglich sind Teams an Microservices- und Micro-Frontend-Projekten beteiligt.
- vertikal aufgeteilt – da auch Frontend-Entwickler, Datenexperten, Backend-Ingenieure, QA-Ingenieure usw. an demselben Projekt arbeiten, erstellen sie ihre Funktionen aus dem Benutzerschnittstelle zu Datenbanken; und
- funktionsübergreifend – jedes Teammitglied bringt seine Expertise in die Gruppe ein.
Teams können auch den Tech-Stack auswählen, der am besten zu ihrer jeweiligen Branche passt.
Ein Team kann React verwenden, um sein Fragment zu programmieren. Ein anderes Team erstellt eine neue Angular-Version. Vue.js ist ein solches Beispiel.
Micro-Frontends werden in Verbindung mit verwandten Microservices verwendet, um Probleme anzugehen, die Entwicklungsteams typischerweise mit Monolithen haben. Die Strategie bietet folgende Vorteile.
- Technologiefreiheit: Frontend-Ingenieure können je nach den Anforderungen des Unternehmens alternative JavaScript-Frameworks, Laufzeitumgebungen und ganze Technologie-Stacks auswählen. Zusätzlich zu der veralteten Architektur kann ein neues Framework angewendet werden.
- Ein größeres Maß an Flexibilität ist möglich, da jedes Mikro-Frontend in sich abgeschlossen ist und separat entwickelt, getestet, bereitgestellt und aktualisiert werden kann. Wenn also ein Team an einer Funktion arbeitet und eine Fehlerbehebung vorangetrieben hat und ein anderes Team seine eigene Funktion hinzufügen muss, müssen sie nicht warten, bis das erste Team seine Aufgabe abgeschlossen hat.
- Autonome Teams und Systeme: Jedes Produktteam und folglich jede Funktion kann mit geringer Abhängigkeit von anderen funktionieren, was es ermöglicht, auch dann weiterzuarbeiten, wenn die Komponenten in der Nähe nicht verfügbar sind.
- Mehrere, kleinere Codebasen: Jedes der Mikro-Frontends wird seine eigene, überschaubarere, kleinere Codebasis haben. Weniger Menschen werden sich auf eine bestimmte UI-Komponente konzentrieren, Codeüberprüfungen vereinfachen und die Gesamtorganisation verbessern.
- Einfache App-Skalierung: Ein weiterer Vorteil von Micro-Frontends ist die Möglichkeit, jedes Feature einzeln zu skalieren. Im Gegensatz zu Monolithen, bei denen jedes Mal, wenn ein neues Feature hinzugefügt wird, das gesamte Programm skaliert werden muss, wird der gesamte Prozess dadurch sowohl zeit- als auch kosteneffizienter.
Wie funktioniert das Mikro-Frontend?
Wie wir bereits erwähnt haben, sind Teams innerhalb der Mikro-Frontend-Architektur vertikal organisiert, was bedeutet, dass sie nach Domänenwissen oder Zweck getrennt sind und von Anfang bis Ende für ein bestimmtes Produkt verantwortlich sind.
Es kann ein oder zwei Backend-Microservices sowie ein kleines Frontend haben. Lassen Sie uns die Eigenschaften dieses visuellen Elements, die Interaktionen mit anderen UI-Komponenten und die Einbindung in die Homepage genauer untersuchen.
Ein Mikro-Frontend kann sein
- eine ganze Seite (z. B. eine Produktdetailseite) oder
- Bereiche der Seite, die von anderen Teams verwendet werden können, wie Kopfzeilen, Fußzeilen und Suchleisten.
Sie können eine große Website in mehrere Seitentypen aufteilen und jeden Typ einem bestimmten Mitarbeiter zur Bearbeitung zuweisen.
Allerdings kommen mehrere Komponenten häufig auf zahlreichen Seiten vor, wie z. B. Kopfzeilen, Fußzeilen, Vorschlagsblöcke usw. Ein Vorschlagsblock kann beispielsweise auf einer Startseite, einer Produktdetailseite oder sogar der Checkout-Seite enthalten sein.
Im Wesentlichen können Teams Teile erstellen, die andere Teams auf ihren Seiten verwenden können.
Die Mikro-Frontends können jedoch im Gegensatz zu den wiederverwendbaren Komponenten separat als unterschiedliche Projekte bereitgestellt werden.
All das klingt fantastisch, aber um eine einheitliche Oberfläche zu schaffen, müssen Seiten und Fragmente irgendwie kombiniert werden.
Dies erfordert eine Frontend-Integration, die über eine Vielzahl von Strategien erreicht werden kann, darunter Routing, Komposition und Kommunikation (siehe Grafik oben).
Routing
Wenn ein Dienst von einer Seite, die von einem Team kontrolliert wird, erforderlich ist, um auf eine Seite zuzugreifen, die einem anderen Team gehört, ist Routing für die Integration auf Seitenebene nützlich.
Jedes Mikro-Frontend wird als Single-Page-Anwendung behandelt. Einfache HTML-Links können verwendet werden, um Routing bereitzustellen.
Ein Benutzer kann den Browser zwingen, das Ziel-Markup von einem Server herunterzuladen und die aktuelle Seite durch die neue zu ersetzen, indem er auf Hyperlinks klickt.
Die App-Shell ist das absolute Minimum an HTML, CSS und JavaScript, das eine Benutzeroberfläche antreibt. Auch wenn die vom Server angeforderten Inhaltsdaten noch warten, erhält der Nutzer sofort eine statisch angezeigte Seite. Die zentrale App-Shell dient als übergeordnete Anwendung für die von den verschiedenen Teams erstellten Single-Page-Apps.
Unabhängig von der verwendeten Bibliothek oder dem verwendeten Framework ermöglichen Meta-Frameworks die Verschmelzung verschiedener Seiten zu einer einzigen.
Zusammensetzung
Komposition ist der Prozess, die Teile so anzuordnen, dass sie in die entsprechenden Bereiche auf einer Seite passen. In den meisten Fällen ruft das Team, das die Seite bereitstellt, den Inhalt des Fragments nicht sofort ab.
Stattdessen platziert es einen Platzhalter oder eine Markierung an der Stelle, an der sich das Fragment im Markup befinden sollte.
Unter Verwendung eines anderen Zusammensetzungsverfahrens wird die endgültige Montage erreicht. Die Zusammensetzung kann in zwei grundlegende Kategorien unterteilt werden: clientseitig und serverseitig.
Clientseitige Komposition: Der Webbrowser wird verwendet, um HTML-Markup zu erstellen und zu bearbeiten. Jedes Mikro-Frontend hat die Möglichkeit, sein Markup separat vom Rest der Seite zu ändern und anzuzeigen.
Webkomponenten ermöglichen Ihnen beispielsweise diese Art der Konstruktion.
Der Plan ist, jedes Fragment in eine Webkomponente zu verwandeln, die unabhängig als a.js-Datei installiert werden kann, wonach die Apps sie laden und in den dafür vorgesehenen Bereichen im Designlayout rendern können.
Webkomponenten sind abhängig von der HTML- und DOM-API, die andere Frontend-Frameworks verwenden können, sowie von einer Standardmethode zum Senden und Empfangen von Daten über Props und Events.
Serverseitige Komposition: Bei diesem Design werden die UI-Teile auf dem Server kombiniert, was dazu führt, dass eine vollständig geformte Seite an die Clientseite gesendet wird, wodurch das Laden beschleunigt wird.
Die Assemblierung wird oft von einem separaten Dienst durchgeführt, der sich zwischen dem Webbrowser und den Webservern befindet. CDN ist eine Instanz des Dienstes (Content Delivery Network).
Sie können je nach Ihren Bedürfnissen eine oder eine Kombination aus beiden wählen.
Mikro-Frontend-Kommunikationsmuster
Die Mikro-Frontend-Architektur funktioniert am besten, wenn es wenig bis gar keine Interaktion zwischen den verschiedenen Komponenten gibt. Mikro-Frontends müssen gelegentlich miteinander sprechen und Informationen austauschen. Hier sind einige mögliche Muster, die dazu führen könnten.
- Web-Worker: Ein Online-Worker ist ein Mechanismus, der es Webinhalten ermöglicht, JavaScript im Hintergrund auszuführen, unabhängig von anderen Skripten und ohne die Geschwindigkeit der Seite zu beeinträchtigen. Für jede Mikro-App wird eine eindeutige Worker-API bereitgestellt. Dieser Vorteil besteht darin, dass zeitaufwändige Arbeiten in einem anderen Thread erledigt werden können, wodurch der UI-Thread fortgesetzt werden kann, ohne verlangsamt oder angehalten zu werden.
- Ereignissender: In diesem Fall kommunizieren viele Komponenten miteinander, indem sie Zustandsänderungen in den Komponenten, die sie abonniert haben, überwachen und darauf reagieren. Andere Mikro-Frontends, die dieses bestimmte Ereignis abonniert haben, reagieren, wenn ein Mikro-Frontend dieses Ereignis auslöst. Ein Event-Emitter, der in jedes Micro-Frontend eingeführt wurde, macht dies möglich.
- Rückrufe und Requisiten: In diesem Abschnitt definieren Sie eine übergeordnete Komponente und untergeordnete Komponenten. Die Kommunikation ist in einer baumartigen Struktur organisiert. Übergeordnete Komponenten verwenden Requisiten, um die Daten als Funktionen den Komponentenbaum hinunter zu den untergeordneten Komponenten zu übermitteln. Im Gegenzug kann das Kind die Eltern effizient benachrichtigen, wenn etwas in seinem Zustand passiert, indem es auf Rückrufe reagiert. React verwendet diesen Modus.
Vorteile des Micro-Frontends
Entwicklung in schnell autonomen Teams
Ein unabhängiges Team kann jeden Teil einer Web-App oder Website erstellen, wenn eine Mikro-Frontend-Methode verwendet wird.
Jedes Team ist völlig autonom, was bedeutet, dass es für den gesamten Komponentenentwicklungszyklus verantwortlich ist, von der Konzeption über die Freigabe bis hin zur Postproduktion.
Darüber hinaus bedeutet dies, dass verschiedene Teams nahtlos zusammenarbeiten können, während sie gleichzeitig an demselben Projekt arbeiten.
Daher sind Release-Zyklen wesentlich schneller als bei Front-End-Monolithen.
Kleinere Codebasen einzelner Mikro-Frontends führen zu saubererem Code
Monolithische Frontends haben große, unhandliche Codebasen, die mit der Zeit immer chaotischer und schwieriger zu verwalten werden.
Micro-Frontends gehen dieses Problem an. Der Quellcode jedes Mikro-Frontends ist überschaubarer, da er kleiner, einfacher und kompakter ist.
Die gesamte Weblösung profitiert folglich von einem saubereren Code.
Verbesserte App-Stabilität aufgrund einer losen Kopplung
Eine Weblösung lässt sich selten in völlig unabhängige Teile aufteilen. Folglich sprechen Mikro-Frontends miteinander.
Trotz der losen Konnektivität ist jedoch jede Verbindung zwischen den Komponenten von Bedeutung.
Der Ausfall einer Komponente hat wenig bis gar keine Auswirkungen auf den Betrieb aller anderen Komponenten, was die verbesserte Stabilität einer Weblösung bietet.
Das Testen einzelner Funktionen wird vereinfacht
Dieser Vorteil ergibt sich aus den Eigenschaften von Micro-Frontends. Basierend auf diesem architektonischen Design ist die Clientseite einer Weblösung modular und jedes Modul ist autonom.
Infolgedessen ist es für ein Team einfacher, einen kleinen Teil der Benutzeroberfläche selbst zu evaluieren, als einen massiven Monolithen zu testen.
Reduzierte Bundle-Größe führt zu schnellerem Laden der Seite
Einer der Hauptgründe für verzögerte Ladezeiten in funktionsreichen monolithischen Websystemen ist die Größe eines JavaScript-Pakets. Auf der anderen Seite erleichtert ein Mikro-Frontend-Ansatz die Reduzierung der Seitenladezeit.
Ein Browser muss unnötigen Code nicht wiederholt herunterladen, da eine Webseite aus mehreren kleinen Bündeln besteht. Dadurch werden Seitenleistung und Ladezeiten erhöht.
Technologieunabhängigkeit
Mehrere Frontend-Frameworks kann von Entwicklern verwendet werden, um eine einzelne Online-Lösung mit einer Mikro-Frontend-Architektur zu erstellen.
Da jede Komponente autonom ist, kann sie mit der Technologie konstruiert werden, die am besten zu den Aufgaben des Teams passt.
Natürlich sollten Programmierer Vorsicht walten lassen, wenn sie Frameworks für das Softwareprojekt auswählen, für das sie verantwortlich sind, und Rücksprache mit anderen Teams ist dennoch dringend angeraten.
Es besteht jedoch keine Chance, dass Sie gezwungen sind, für die Dauer der Lebensdauer der App ein Legacy-Framework zu verwenden.
Nachteile von Micro Frontend
Testen komplexer Weblösungen in ihrer Gesamtheit
Das Testen der verschiedenen Module einer Weblösung ist einfach, wenn sie eine Mikro-Frontend-Architektur verwendet. Es unterscheidet sich jedoch von der Bewertung einer Webanwendung als Ganzes.
Vergewissern Sie sich, dass alle Teile wie vorgesehen funktionieren, bevor Sie fortfahren. Dies kann schwierig sein, da Mikro-Frontends unabhängig voneinander arbeiten und separate Bereitstellungsprozesse haben.
Teure Anfangsinvestitionen
Micro-Frontend-Entwicklungen erfordern in der Regel erhebliche finanzielle Aufwendungen. Es ist teuer, viele Front-End-Teams zusammenzustellen und zu unterhalten.
Darüber hinaus benötigen Sie Führungskräfte, die den Job organisieren, für die Koordination sorgen und eine hervorragende Teamkommunikation gewährleisten.
Die Komplexität von Entwicklung und Bereitstellung
Die Entwicklungs- und Bereitstellungsverfahren können durch ein Mikro-Frontend-Design komplizierter werden.
Eine Lösung könnte beispielsweise von unabhängigen Entwicklungsteams, die am selben Projekt arbeiten, mit zu vielen Komponenten überladen werden, was zu Problemen in der Bereitstellungsphase führen könnte.
Auch die richtige Montage aller Module und deren reibungslose Integration in das Gesamtkonzept ist nicht immer einfach; Diese Arbeit erfordert in der Regel ein gründliches Verständnis aller Abhängigkeiten.
Probleme bei der Aufrechterhaltung der Kohärenz in der Benutzererfahrung
Die Aufrechterhaltung einer konsistenten Benutzeroberfläche ist eine Herausforderung, wenn Teams separat an mehreren Teilen der Software arbeiten.
Die Weblösung sollte von allen Entwicklern des Projekts gemeinsam genutzt werden. Andernfalls kann es auf dem Weg zu vielen Widersprüchen kommen.
Zusammenfassung
Mikro-Frontends, ein zeitgemäßes Architekturdesign, können die Leistung großer, auf Microservices basierender Webentwicklungsprojekte erheblich verbessern.
Es ermöglicht Programmierern, die komplette Lösung in diskrete Teile zu unterteilen, die von mehreren autonomen Teams erstellt werden können. Daraus ergeben sich zahlreiche Vorteile, darunter eine schnellere Einführung von Funktionen, einfacheres Testen einzelner Module und nahtlosere Upgrades.
Aber auch bei Micro-Frontends gibt es einige Schwierigkeiten.
Das umfassende Testen einer Anwendung kann beispielsweise eine Herausforderung darstellen.
Da außerdem ein großes Team von Ingenieuren und Administratoren benötigt wird, sind Mikro-Frontend-Projekte sehr teuer.
Bevor Sie eine Entscheidung treffen, müssen Sie daher alle Komponenten Ihres Business Case berücksichtigen.
Vladimír Čamaj
Irgendwie habe ich nicht verstanden, nach welchem Prinzip die Kommunikation zwischen einzelnen Komponenten im Frontend funktioniert. Ich verstehe nicht, wie Sie Komponenten verbinden möchten, die in verschiedenen Frameworks erstellt wurden. Darüber steht im Artikel nichts. Das System aus Ereignissen und Zuhörern sieht für mich wie die Hölle auf Erden aus. Wie sollen wir uns das vorstellen?