Smashing Podcast Folge 6 mit Luca Mezzalira: Was sind Micro-Frontends?

Wir schließen dieses Jahr mit einem weiteren Smashing-Podcast ab! Diesmal sprechen wir über Micro-Frontends. Was ist ein Mikro-Frontend? Wie unterscheidet es sich von der Art der Herangehensweise, die wir derzeit verfolgen? Lassen Sie es uns vom Micro-Frontend-Pionier Luca Mezzalira herausfinden.

Notizen anzeigen

Wöchentliches Update

• „Hinzufügen dynamischer und asynchroner Funktionalität zu JAMstack-Sites“, Jason Lengstorf
• „Quantitative Datentools für UX-Designer“, Adonis Raduca
• „Erstellen von Voice Skills für Google Assistant und Amazon Alexa“, Tris Tolliday
• „Beyond Sprint 0: Eine Alternative für die Integration von Teams“, Shamsi Brinn
• „Unterstützung von Browsern bei der Optimierung mit der CSS Contain-Eigenschaft“, Rachel Andrew

Mikro-Frontends

• Website von Luca Mezzalira
• Lukas auf Twitter
• „Micro-Frontends, die Zukunft der Frontend-Architekturen“ auf Medium
• Weitere Beiträge von Luca über Micro-Frontends finden Sie auf seinem Medium-Konto
• Lucas Buch „Front-End Reactive Architectures“

Abschrift

Drew McLellan: Er ist Google-Entwicklerexperte für Webtechnologien und Manager der Londoner JavaScript-Community. Mit mehr als 15 Jahren Erfahrung arbeitet er derzeit als VP of Architecture und entwirft die Sportvideoplattform DAZN, die Sportinhalte auf Abruf für Millionen von Benutzern bereitstellt, die alle live zuschauen. Er ist Autor des Buches Front-End Reactive Architectures für Apress und technischer Gutachter für Apress, Packt Publishing, Pragmatic Bookshelf und O'Reilly sowie ein erfahrener Redner auf technischen Konferenzen auf der ganzen Welt. Er ist Italiener, trägt einen hübschen Bart und verfügt eindeutig über fundierte Kenntnisse der Webplattform. Aber wussten Sie, dass er einst auf einem Strauß Südamerika durchquerte? Meine großartigen Freunde, bitte heißen Sie Luca Mezzalira willkommen. Hallo Luca. Wie geht es dir?

Luca Mezzalira: Ich bin überwältigend.

Drew: Ich möchte heute mit Ihnen über das Thema Micro-Frontends sprechen. Nun, das ist ein Konzept, das mir völlig neu ist, sicherlich dem Namen nach, und ich gehe davon aus, dass es auch vielen unserer Zuhörer neu ist. Bevor wir uns mit Mikro-Frontends selbst befassen, sollten wir wohl das Problem verstehen, das Sie damit lösen möchten. Vielleicht könnten Sie uns also ein wenig darüber erzählen, wie Sie Anwendungen auf traditionellere Weise sehen und welche Art von Problemen diese Dinge haben, für die Mikro-Frontends vielleicht die Lösung sein könnten?

Luca: Okay, das ist meiner Meinung nach ein guter Ausgangspunkt. Wenn Sie also ein neues Green-Field-Projekt implementieren oder entwerfen und mit Front-End-Anwendungen arbeiten möchten, haben Sie normalerweise einige Architekturen, die Sie nutzen können. Sie können eine Einzelseitenanwendung verwenden, Sie können eine serverseitige Renderinganwendung verwenden, oder Sie können eine mehrseitige Anwendung verwenden, die nur aus einfachen HTML-Seiten besteht. Offensichtlich sind das super gültige Optionen und ich denke, dass sie von vielen, vielen Entwicklern sehr genutzt werden. Das eigentliche Problem, das wir hier zu lösen versuchen, ist, wie Sie diese Konzepte mit verteilten Teams auf Hunderte von Entwicklern skalieren können, die an derselben Codebasis arbeiten, denn die Realität ist, wenn Sie insbesondere auf diesen Plattformen arbeiten, wenn Sie darüber nachdenken SaaS-Plattform benötigen Sie beispielsweise mehrere Entwickler und mehrere Teams, die an demselben Projekt arbeiten. Und natürlich unterscheidet sich die Art und Weise, wie Sie zum Beispiel Akquise oder Bindung betreiben, völlig von der Art und Weise, wie Sie den Katalog ausstellen oder wie Sie einen bestimmten Teil einer Plattform zeigen.

Luca: Meiner Erfahrung nach arbeite ich also viel mit Single-Page-Bewerbungen. Ich arbeite mit einer serverseitigen Rendering-Anwendung, aber irgendwann bei DAZN wurde ich gebeten, über eine Möglichkeit nachzudenken, unser technisches Team zu skalieren. Und ich muss kommen … wenn wir für das Backend eine Lösung haben, die in diesem Fall Microservices sind, damit wir unsere APIs unabhängig skalieren und die Skalierung und das Volumen für einen bestimmten Durchsatz auf einer bestimmten API berücksichtigen können. Am Frontend ist es wirklich schwieriger, denn wenn Sie darüber nachdenken, müssen Sie kein technisches Problem lösen, wenn Sie skalieren müssen, wenn Sie beispielsweise eine Single-Page-Anwendung verwenden. Wahrscheinlich haben Sie einige für ein serverseitiges Rendering, aber bei einer Single-Page-Anwendung wird es beispielsweise von Natur aus verteilt, weil es auf der Client-Seite und auf der anderen Client-Seite ist.

Luca: Das einzige, was sie laden, sind nur einige statische Dateien wie CSS und HTML und JavaScript, die von CDN bereitgestellt werden, und in diesem Fall können Sie entsprechend skalieren, es ist keine große Herausforderung. Aber die eigentliche Herausforderung besteht darin, wie Sie die Teams skalieren, die auf derselben Plattform arbeiten, denn manchmal können sich die Herausforderungen, denen ein Team gegenübersteht, völlig von den Herausforderungen unterscheiden, denen ein anderes Team gegenübersteht, und normalerweise versuchen Sie, etwas zu finden viele Kompromisse zwischen den Dingen. Denn wenn Sie denken, versuchen wir, an einen normalen Anwendungsfall zu denken. Wenn Sie also eine Plattform starten, fangen Sie normalerweise klein an. Sie versuchen also, diese schnelle Single-Page-Anwendung zu erstellen, außerdem haben Sie Ihren Monolithen, also richten Sie alles in Ihrem CICD nur einmal für Front-End und Back-End ein und beginnen dann, Ihre Logik zu iterieren. Aber die Realität ist, wenn Sie Erfolg haben, müssen Sie diesen Teil weiterentwickeln, und es ist nicht immer die Beibehaltung derselben Architektur, die, sagen wir, den Nutzen für Ihr Unternehmen schaffen könnte, weil Sie vielleicht einige Engpässe finden können.

Luca: Nun zurück zum Teil der einseitigen Bewerbung. Wenn wir also einen Single-Page-Anwendungsteil skalieren wollen, ist die Herausforderung nicht technisch, sondern mit Menschen, wenn Sie wollen. So können wir Teams skalieren, die an derselben Anwendung arbeiten. Was ich also vor ein paar Jahren getan habe, war, mich mit einer möglichen Architektur und Prinzipien zu befassen, die es mir ermöglichen würden, sowohl das Frontend als auch das Backend zu skalieren. Arbeiten Sie also an den Backend-Prinzipien, damit Sie die Microservices finden können. Ich fing an, mir die anderen Lösungen anzusehen, und sie kamen mit den Mikro-Frontends heraus, die wir am Anfang nicht einmal so nannten, weil es offensichtlich vor Jahren nicht diesen, sagen wir, diesen Namen für diese spezifische Architektur gab .

Luca: Aber die Realität ist, einen Monolithen zu nehmen, also eine Single-Page-Anwendung, und sie so aufzuteilen, dass wir uns auf ein winziges Problem konzentrieren können. Also ein kleineres Problem als die gesamte Anwendung und versuchen, das bestmöglich zu lösen. Technisch gesagt. Offensichtlich führt dies dazu, dass Sie unabhängige Teile Ihrer Frontend-Anwendung haben, die in der Produktion bereitgestellt werden können, ohne alle anderen zu beeinträchtigen. Die Herausforderung für Micro-Frontend besteht also im Grunde darin, einen Weg zu finden, eine Single-Page-Anwendung oder eine serverseitig gerenderte Anwendung zu nehmen und daraus ein Artefakt zu erstellen, sagen wir, das so nah wie möglich an einer Geschäftsdomäne liegt und unabhängig bereitgestellt werden kann .

Drew: Ich meine, Sie haben Microservices im Backend erwähnt. Also konzeptionell ist dies eine ähnliche Lösung für das Problem. Die Microservices werden im Backend bereitgestellt, aber auf das Frontend portiert. Ist das eine ungefähre Äquivalenz oder ist es mehr damit verbunden?

Lukas: Ja. Nein, es ist eine Möglichkeit, das gleiche Problem zu lösen, mit dem versucht wird, Microservices im Backend, aber in dieser Zeit im Frontend zu lösen. Wenn ich diese Reise am Anfang angetreten habe, fängst du normalerweise an, darüber nachzudenken und beginnst, verschiedene Ansätze zu bewerten. Und in den letzten Monaten habe ich das entwickelt, was sie Micro-Frontend-Entscheidungsrahmen nennen, der im Grunde aus vier Schritten besteht, die sie verwenden, um, sagen wir, Sie einen Ansatz für Micro-Frontend zu identifizieren, denn wenn wir es bisher getan haben Wählen Sie normalerweise ein Framework aus, das die Architektur für uns entworfen hat, und wir implementieren es auf der Grundlage ihrer Architektur. Wenn Sie an eckig denken oder an React oder Redux denken. Sie haben alle Teile, die benötigt werden, aber Sie treffen keine architektonischen Entscheidungen. Sie würden Designentscheidungen treffen oder wie Sie diese spezifische Architektur implementieren.

Luca: Auf dem Micro-Frontend müssen Sie also den Schritt zurück beginnen. Wir müssen uns also überlegen, wie wir unsere Anwendung zuerst aufteilen wollen. Dafür gibt es in der Regel zwei Möglichkeiten. Sie können horizontal aufteilen, sodass Sie mehrere Mikro-Frontends in derselben Ansicht haben können, oder Sie können vertikal aufteilen. Daher laden Sie immer ein Micro-Frontend pro Mal. Und diese Entscheidung ist ziemlich wichtig, weil sie dann bestimmte andere Optionen, die Sie basierend auf der anfänglichen Entscheidung haben, kaskadieren wird. Wie ich bereits sagte, entscheiden Sie also zunächst, wie Sie Ihre Anwendung aufteilen möchten. Die zweite ist, wie Sie Ihre Bewerbung verfassen möchten. Sie möchten also beispielsweise eine App-Shell haben, die ein oder mehrere Mikro-Frontends in derselben Ansicht lädt. Sie möchten, ich weiß nicht, einen Anwendungsserver haben, der verschiedene Fragmente Ihrer Anwendungen zusammensetzt, also verschiedene Mikro-Frontends, und dann Ihrem Benutzer die endgültige Ansicht bereitstellen. Oder Sie möchten Edge-Side-inklusive verwenden, es ist ein Standard, der sich innerhalb von CDNs befindet, um eine Seite zu erstellen und diese dort bereitzustellen.

Luca: Das sind drei der Optionen, die Sie haben. Und dann müssen Sie, abgesehen vom Komponieren, darüber nachdenken, wie Sie routen möchten. Wie Sie also von, ich weiß nicht, /login oder /signin zum Katalogteil oder einem bestimmten Detailobjekt leiten. Auch hier haben Sie drei Möglichkeiten. Sie können dies auf dem Anwendungsserver tun, Sie können es auf CDN-Ebene mit Lambda Edge oder anderen Webworkern in CloudFlare oder irgendetwas anderem tun. Oder Sie können eine Kundenseite erstellen. Sie haben also eine Logik in Ihrer App-Shell, die Sie sagen, okay, jetzt müssen Sie für diese bestimmte URL eine andere Ansicht oder ein anderes Mikro-Frontend laden. Und das Letzte ist, wie Sie mit Micro-Frontend kommunizieren.

Luca: Wenn Sie also mehrere Micro-Frontends auf derselben Seite haben, ist die Verwaltung dieser Kommunikation normalerweise komplexer, da Sie die verschiedenen Micro-Frontends unabhängig voneinander pflegen müssen. Das bedeutet, dass Sie keinen Hinweis darauf haben können, wie die Seite aufgebaut ist. Normalerweise können Sie also Dinge wie benutzerdefinierte Ereignisse oder einen Ereigniszähler verwenden, der in jedes einzelne Mikro-Frontend eingefügt wird. Und dann kommunizieren die Micro-Frontends miteinander. Offensichtlich ist es im anderen Fall, wenn Sie beispielsweise eine vertikale Abspaltung Ihres Micro-Frontends haben, viel einfacher, da innerhalb der Vertikalen im Grunde die Darstellung eines vertikalen Micro-Frontends eine Single-Page-Anwendung oder eine einzelne Seite ist. Und in diesem Fall ist es beispielsweise einfacher, einen gemeinsamen Zustand über das gesamte Micro-Frontend zu erstellen und zu teilen.

Luca: Wenn Sie dann darüber nachdenken, mehrere Micro-Frontends alle zusammen zu haben, dann sollten Sie vermeiden, Zustände zu haben, die über Micro-Frontends geteilt werden, da Sie sonst Dinge koppeln. Anstelle des ganzen Konzepts steht hier die Entkopplung und der unabhängige Einsatz. Nehmen wir also an, die Herausforderungen einer horizontalen Aufteilung, die die erste Entscheidung ist, die Sie treffen sollten, oder einer vertikalen Aufteilung sind völlig unterschiedlich, und wir müssen uns sehr bewusst sein, welche für unseren Anwendungsfall geeignet ist.

Drew: Also eher als eine spezifische technische Lösung, sind Mikro-Frontends eher wie ein Designmuster, das Sie in jeder Technologie implementieren würden, die für das spezielle Problem, das Sie zu lösen versuchen, geeignet ist?

Luca: Ja, mehr als Technologie würde ich dafür sorgen, dass wir die richtige Architektur für den richtigen Job auswählen. Nur um Ihnen ein Beispiel zu geben, ich sprach … es gibt ein berühmtes Framework, ein ziemlich neues für Micro-Frontends, es heißt Luigi-Framework, das von SAP Open Source veröffentlicht wurde. Was sie tun, ist, einige Iframes zu erstellen, in die sie ihr Micro-Frontend einpacken. Wenn Sie also jetzt darüber nachdenken, sagen wir, wenn Sie heutzutage iFrames verwenden, befinden Sie sich auf einer öffentlichen Website, die möglicherweise als SEO oder andere obligatorische Funktionen problematisch sein könnte.

Luca: Aber im Fall von SAP, wenn Sie darüber nachdenken, haben sie eine Art Unternehmensanwendung, mit der sie den Browser steuern können, den der Benutzer verwendet, sie können die Umgebung steuern, sie müssen nicht auf einer Vielzahl verfügbar sein oder andere Version des Browsers. Für sie ermöglicht dieses Ding ihnen also, bestimmte Anwendungsbereiche zu haben, die konstant sind, und sie haben bestimmte Bereiche, die sich unabhängig voneinander ohne Probleme ändern. Aber offensichtlich würde eine Iframe-Lösung in einer anderen Situation nicht funktionieren. Nur um ein anderes Beispiel zu nennen, Spotify, wir verwenden am Anfang Iframes. Tatsächlich besteht die Schreibtischpublikation immer noch aus mehreren Iframes, und jeder einzelne Iframe ist eine winzige Anwendung, die, ich weiß nicht, nur einen Musikplayer oder nur ihre Empfehlung macht, was auch immer es ist. Sie versuchen, den gleichen Ansatz im Web zu verfolgen, haben dies jedoch dieses Jahr verworfen, um zu einer Single-Page-Anwendung zurückzukehren.

Luca: Und das heißt, sie erklären im technischen Blog, warum sie das offensichtlich gesagt haben, wenn man das auf Millionen von Benutzern anwendet, die Iframes verwenden, die jedes Mal dieselbe Anbieterdatei laden müssen. Und dann haben Sie viele Abhängigkeiten dupliziert und die Zeit für die Interaktion mit Ihrer Seite wäre länger. In Wirklichkeit könnte dieser Ansatz also für bestimmte Anwendungsfälle geeignet sein, aber sie sollten nicht für alle geeignet sein. Deshalb sage ich, wie ich zuvor beschrieben habe, wenn Sie einen Entscheidungsrahmen haben, der Ihnen hilft, diese Dinge anzugehen, und Sie anfangen können zu sagen, okay, ich habe die Anwendung auf diese Weise aufgeteilt, also habe ich diese Optionen, die verfügbar sind Wenn ich komponieren möchte, wenn ich routen möchte, wenn ich kommunizieren möchte, sollte es Sie leiten, um zur richtigen Zeit die richtige Entscheidung zu treffen.

Luca: Abgesehen von diesen vier Entscheidungen gibt es natürlich noch viele andere. Zum Beispiel, wie Sie Konsistenz im Designsystem schaffen, das Sie über das gesamte Micro-Frontend haben. Oder ich weiß nicht, wie Sie die Abhängigkeiten verwalten und das Aufeinanderprallen der Abhängigkeiten innerhalb des Micro-Frontends vermeiden, aber die Realität ist, dass diese vier Entscheidungen, die ich zuvor erwähnt habe, es Ihnen ermöglichen, alle anderen schnell zu treffen, ohne zu müssen das Problem des Überdenkens, was die beste Lösung ist, weil Sie bereits den Grundstein gelegt haben, die vier Säulen, die es Ihnen ermöglichen, alle anderen Entscheidungen zu treffen … Ich sage nicht auf einfache Weise, aber auf schnellere Weise als eine Überprüfung oder das Spektrum der Möglichkeiten.

Drew: Sie haben bereits erwähnt, dass Micro-Frontend bei der Art der Teamstruktur in Ihrer Organisation helfen kann und viele Leute an derselben Anwendung arbeiten. Was sind dann einige der Implikationen und macht es einen Unterschied, ob Ihre Teams verteilt oder gemeinsam angesiedelt sind, oder gibt es dort irgendwelche Herausforderungen?

Lukas: Ja. Also kann ich dir erzählen, was die Geschichte von DAZN ist. Das ist die Firma, in der ich arbeite. Derzeit hatten wir bei DAZN eine schöne Herausforderung. Aktuell arbeiten also über 300 Leute am Front- und Backend unserer Plattform. Es ist eine OTT-Plattform, die weltweit bei Sportveranstaltungen live streamt. Und das Interessante ist, wenn wir alle Microservices mehr oder weniger zu verwalten wissen und wir verteilte Teams haben. Wir haben also vier Entwicklungszentren. Wir würden Teams in jedem einzelnen Entwicklungszentrum an der Front platzieren wollen, und wir haben diesen Ansatz ausprobiert und er funktioniert ziemlich gut. Mit Micro-Frontend konnten wir also verschiedene Geschäftsdomänen an verschiedenen Standorten bereitstellen und die Querkommunikation zwischen Teams innerhalb einer bestimmten Geschäftsdomäne ermöglichen, da das Worst-Case-Szenario darin besteht, dass Sie mit einem anderen Team in derselben Geschäftsdomäne sprechen müssen , erreichen Sie von Ihrem Schreibtisch aus nur wenige Gehminuten. Wenn Sie stattdessen bestimmte Dinge im Vertriebsteam besprechen müssen, also vielleicht mit jemandem in London statt in Amsterdam oder statt mit der Firma in Polen, organisieren Sie einfach einen Anruf.

Luca: Aber diese Art der Kommunikation ist seltener als die, die zwischen Teams am selben Ort stattfindet. Und deshalb haben wir angefangen, daran zu arbeiten. Als erstes haben sie sich angesehen, wie unsere Benutzer mit unserer Website interagieren und wie das Unternehmen strukturiert ist. Und wenn wir die vier Schlüsselbereiche identifizieren, an denen wir arbeiten, die derzeit Akquisition und Bindung sind, sagen wir, die Portierung ihrer Kernanwendung auf mehrere Fernseher und Mobilgeräte und die Kerndomäne, die für uns der Videoplayer und die Entdeckungsphase sind unsere Inhalte. Und schließlich alle Backoffice-Elemente. Ich konnte diese vier Bereiche identifizieren und wir diese vier Bereiche, die wir jedem einzelnen Entwicklungszentrum zugewiesen haben.

Luca: Offensichtlich gibt es einige Berührungspunkte zwischen diesen Bereichen, aber dann gibt es Möglichkeiten, die Sie, sagen wir, abmildern und einen ersten Workshop mit den verschiedenen Teams an verschiedenen Standorten durchführen und dann beispielsweise auf denselben API-Vertrag hinarbeiten können, oder das gleiche Ziel mit einigen Checkpoints während der Entwicklung. Aber das Schöne an der Annäherung an diese erlaubte Annäherung mit Micro-Frontend ist die Tatsache, dass wir endlich genau verstehen, wie unser System funktioniert. Wir setzen uns hin und analysieren, wie wir strukturiert waren, und wir haben nicht nur die Art und Weise verändert, wie wir betroffen waren, sondern auch, wie das Unternehmen funktioniert. Und das war eine Art anderer Ansatz als das, was sie bisher gesehen haben. Aber es beweist, dass es ziemlich gut funktioniert, wenn jedes einzelne Team mit dem Team des gleichen Standorts in der gleichen Domäne interagieren kann.

Luca: Sie sprechen also genau dieselbe Sprache, wenn Sie über das domänengetriebene Design sprechen. Und das heißt, wenn sie mit anderen Teams interagieren müssen, können sie den Workshop buchstäblich teilen oder in ein anderes Entwicklungszentrum fliegen, und das ist weniger als ein Problem. Aber sagen wir, auf diese Weise erhöhen wir den Durchsatz und reduzieren den Kommunikationsaufwand und das Ausmaß der Abhängigkeiten, die in anderen Situationen, an denen sie arbeiteten, auftraten.

Drew: Und müssen all diese Teams ein standardisiertes JavaScript-Framework verwenden? Müssen sie alle in den gleichen Dingen codieren, müssen sie alle entweder React oder Angular sein oder die Interoperabilität zwischen ihnen ermöglichen, oder können Leute verschiedene Dinge für verschiedene Micro-Frontends verwenden?

Lukas: Ja. Also haben wir uns bei DAZN entschieden, unser Micro-Frontend vertikal aufzuteilen, und das war eine Entscheidung, die uns die Freiheit gab, die Technologie auszuwählen, die wir für jedes einzelne Micro-Frontend benötigen. Wenn man bedenkt, dass wir jedes Mal ein Mikro-Frontend laden, bedeutet dies beispielsweise, dass sich die Art und Weise, wie wir eine Zielseite haben, von der Anmelde- / Registrierungsreise unterscheidet. Wir können also updaten … wir verwenden im Moment hauptsächlich React. Aber wenn ich mich zum Beispiel erinnere, als React 16 eine Veröffentlichung war, die wir in der Produktion von React 16 veröffentlichen konnten, auch wenn es nicht in der stabilen Version für nur eine Zielseite war, und schaue, ob es funktionierte, ohne alle zu beeinträchtigen andere Mannschaften.

Luca: Und dann haben sie in ihrem eigenen Tempo, in ihrem eigenen Tempo, ihre eigenen Sachen aktualisiert. So können wir beispielsweise auch neue Technologien oder neue Annahmen ausprobieren, die wir für die vorhandene Anwendung mit einer bestimmten Anzahl von Benutzern haben. Denn wir implementieren die auch Kandidaten-Releases für das Frontend. Wir implementieren die, sagen wir, mehrere Praktiken, die es uns ermöglichen, bestimmte Zeiten in der Produktion einfach auszuprobieren und zu sehen, wie die Dinge funktionieren.

Luca: Das Schöne an diesen Ansätzen ist, dass wir unabhängig voneinander entscheiden können, das richtige Tool für den richtigen Job zu haben, mehr als einen gemeinsamen Nenner über den gesamten Stack zu haben. Denn wie Sie sich vorstellen können, als Sie anfingen, an einem Projekt zu arbeiten, war die Entscheidung, die Sie in den ersten Jahren getroffen haben, wahrscheinlich anders als die Entscheidung, die Sie in einer Flugbahn getroffen haben, in der das Unternehmen wächst, sich das Geschäft weiterentwickelt und diese reifer wurden und die Herausforderung ist eine ganz andere. Es wäre also nicht flexibel genug oder agil genug, wenn man darüber nachdenkt, dass wir an der gleichen Entscheidung festhalten, die wir vor zwei Jahren getroffen haben. Insbesondere eine Institution wie DAZN, die wir in drei Jahren von praktisch null auf 3000 Mitarbeiter bringen. Wie Sie sich also vorstellen können, war es ein massives Wachstum und es war ein massives Wachstum sowohl für das Unternehmen als auch für die Benutzerbasis.

Drew: Gibt es eine etablierte Möglichkeit für die verschiedenen Micro-Frontends, Daten auszutauschen und miteinander zu kommunizieren, um beispielsweise mit derselben Ansicht auf dem Laufenden zu bleiben, oder gibt es eine Möglichkeit, dies zu tun?

Luca: Ja, das gibt es. Es hängt davon ab, welchen Entscheidungsrahmen, welchen Weg Sie einschlagen werden. Denn wenn Sie den vertikalen Schnitt nehmen, wurde das sehr einfach. Was wir also haben, um über das Micro-Frontend zu kommunizieren, ist eine App-Shell, die das Micro-Frontend in sich selbst lädt. Und was es tut, ist alles zu speichern, was, sagen wir, über verschiedene Micro-Frontends oder auf einem Webspeicher geteilt werden muss, entweder eine Sitzung oder ein lokaler Speicher oder im Speicher. Und dann wird das Micro-Frontend auf der Grundlage dieser Informationen geladen, kann diese Informationen von der App-Shell abrufen und diese dann konsumieren, ergänzen oder ändern. Es liegt ganz bei Ihnen, wie Sie die Anwendung aufteilen, aber in diesem Fall nur um ein Beispiel zu geben, wenn Sie denken, wenn Sie authentifizierte Benutzer sind und zur Anmeldeseite gehen müssen, wenn Sie sich anmelden und die APIs von uns verbraucht werden und Sie stellen ein JWT-Token bereit, das Micro-Frontend gibt diese an die App-Shell weiter und die App-Shell, die diese startet, speichert ihren Webspeicher.

Luca: Danach lädt die App-Shell den neuen authentifizierten Bereich für diese spezifische Anwendung und diese authentifizierten Bereiche, sie rufen das JWT-Token von der App-Shell ab und führen entweder ein Aktualisierungs-Zugriffstoken durch oder validieren einige Daten, beginnend innerhalb der JWT-Token. Es verwendet also im Wesentlichen die Informationen, die von einem anderen Micro-Frontend an ihrem eigenen Rad produziert wurden.

Drew: Das klingt nach einem sehr interessanten Konzept und ich sehe potenziell viele große Vorteile darin, auf diese Weise zu arbeiten, aber es kann sicherlich nicht ohne Herausforderungen bleiben. Gibt es bestimmte Dinge, die schwieriger zu handhaben sind, wenn man Dinge auf diese Weise gestaltet?

Luca: Ich denke, die größten Herausforderungen sehe ich in erster Linie im Mentalitätswandel. Denn früher waren wir daran gewöhnt, sagen wir mal, die technischen Leiter oder die leitenden Entwickler, die alles rund um eine ganze Anwendung entschieden und alle Entscheidungen trafen. Jetzt gehen wir endlich von dieser zentralisierten Einheit zu einer dezentralisierten Einheit über, die für jeden Staat lokal ist. Wie Sie sich vorstellen können, bringt dies einige Herausforderungen mit sich, denn wenn wir vorher jemanden hatten, der den Weg verfolgt, haben wir jetzt, sagen wir, mehrere Leute an der Spitze, die den richtigen Weg innerhalb ihrer Domäne definieren, und das ist eine große Veränderung der Denkweise.

Luca: Auf der anderen Seite denke ich, dass die Komplexität darin besteht, manchmal zu akzeptieren, dass die falsche Abstraktion teurer sein könnte als das Duplizieren von Code. Und ich weiß, dass es etwas gibt, das ich bei der Verwaltung von Entwicklern als sehr herausfordernd empfand, weil sie dachten: „Okay, jetzt kann ich dieses Objekt oder diese bestimmte Bibliothek hunderte Male innerhalb des Projekts wiederverwenden“, aber die Realität sieht ganz anders aus. Ich sah Komponentenbibliotheken, die abstrakt waren, und sie verbrachten viel Zeit damit, daraus den besten Code aller Zeiten oder den besten in perfekter Form zu machen. Aber die Realität wurde nur zweimal verwendet. Der Aufwand dafür war also nicht genau das. Ich habe auf der anderen Seite Bibliotheken gesehen, dass sie mit ein paar Anwendungsfällen für eine bestimmte Komponente begannen. Und dann wurden diese Anwendungsfälle 10 und dann wurde der Code nicht mehr wartbar.

Luca: Der Versuch, eine neue Funktion innerhalb derselben Komponente hinzuzufügen, könnte also eher gefährdet als vorteilhaft sein. Ich denke, die andere Sache, die wir mit Micro-Frontend verstehen müssen, ist, wie viel wir es teilen und wie viel wir duplizieren wollen. Und es schadet ehrlich gesagt nicht, zu duplizieren. In unserem Fall haben wir zum Beispiel eine Duplizierung von Fußzeile und Kopfzeile, und das haben wir hauptsächlich gemacht, weil wir die Kopfzeile in vier Jahren etwa dreimal geändert haben. Sie können sich also vorstellen, dass wir diese zentralisieren, einem Team zuordnen und eine externe Abhängigkeit für alle Teams schaffen, all die Hunderte von Entwicklern, die wir haben, sagen wir eher ein Problem, das ein Vorteil für das Unternehmen ist, weil wir fügen keinen enormen Wert hinzu.

Luca: Zur gleichen Zeit refaktorisieren wir derzeit unsere gemeinsam genutzten Bibliotheken, die Zahlungsbibliotheken wären, weil hinter der Zahlung offensichtlich eine gewisse Logik steckt, und wenn wir uns einmal ändern wollen, wollen wir das nicht zweimal in mehreren Teilen anwenden Code. Wir wollen nur eine Bibliothek haben, die eine Quelle der Wahrheit ist, aber für die Kopf- und Fußzeile, auch wenn es eine Diskrepanz gibt oder für Pixel oder eine Funktion, die wie eine Woche später bereitgestellt wird, schadet das nicht Anwendung.

Drew: Gibt es also einige verräterische Anzeichen, auf die die Leute achten sollten, wenn sie eine Anwendung bewerten und denken: „Oh ja, das wäre ein guter Kandidat, um zu einer Micro-Frontend-Architektur überzugehen?“

Luca: Ja, mein Vorschlag wäre in erster Linie, dass ich kein Greenfield-Projekt mit Micro-Frontend starten würde, wenn wir nicht genau wissen, wie es aufgebaut werden soll. Und normalerweise ist es sehr unwahrscheinlich, dass Sie diese Informationen haben, denn insbesondere wenn Sie eine neue Plattform oder ein neues Projekt haben und es das erste Mal ist, dass Sie daran arbeiten, kann es nicht trivial sein, diese Informationen zu finden. Normalerweise schlage ich vor, mit einer bestehenden Architektur zu beginnen, die eine Single-Page-Anwendung wäre, und diese dann weiterzuentwickeln. Insbesondere habe ich festgestellt, dass die Verwendung von Micro-Frontend für Legacy-Anwendungen oder wenn wir einen bestimmten Teil der Anwendung ersetzen möchten oder wenn wir ein Projekt haben, das wir weiterentwickeln und für mehrere Teams skalieren möchten, das sind drei Anwendungsfälle das meiner Meinung nach sehr stark zur Micro-Frontend-Architektur passen könnte. Das heißt natürlich nicht, dass ab jetzt alles Micro-Frontend sein soll, denn Micro-Frontend ist überhaupt nicht der Königsweg.

Luca: Was sie sind, ist eine zusätzliche Architektur, die wir in der Front-End-Welt nutzen können. Und bis jetzt hatten wir so eine gewisse Menge an Architekturen, jetzt haben wir eine zusätzliche. Aber das ist eine Menge Herausforderungen, denn natürlich müssen Sie, wenn es vor dem serverseitigen Rendern oder einer Einzelseitenanwendung klare Muster gibt, die untersucht und dann von mehreren Frameworks usw. implementiert wurden. Mit Micro-Frontend ist dies derzeit eine Möglichkeit, Dinge zu tun. Aber das Hinzufügen des Entscheidungsrahmens sollte es den Menschen wahrscheinlich ermöglichen, die richtigen Entscheidungen für ihre Anwendungsfälle zu treffen. Denn oft gibt es viele Missverständnisse darüber, was Micro-Frontends sind und wie sie verwendet werden sollten. Und viele Leute denken, dass es vielleicht, sagen wir mal, böse ist, weil ich weiß nicht, zu viele Bibliotheken in einer Ansicht oder anderen Dingen zu haben.

Luca: Die Realität ist, dass Sie das Konzept gründlich verstehen müssen, verstehen müssen, wie man es umsetzt, und dann können Sie anfangen, daran zu arbeiten. Ich stimme voll und ganz zu, dass es technische Herausforderungen und viele Entscheidungen gibt, die man treffen muss, und man kann nicht gleich mit einem Redakteur vor sich anfangen, Code schreiben und denken, okay, jetzt erstelle ich ein Micro-Frontend die Architektur. Weil Sie das Konzept verstehen, den Kontext verstehen und erstellen müssen, auch Governance darum herum, denn die Komplexität besteht nicht nur darin, den Code zu schreiben, sondern auch zu verstehen, wie alle Teile im CICD-Teil, im SEO-Teil und so weiter zusammenpassen.

Luca: Micro-Frontend bietet also, sagen wir, ein gewisses Maß an Flexibilität und erfordert viel Aufwand, um das Governance-Recht zu definieren. Denn wenn Sie die richtige Governance haben, wäre alles glatt. Oft und leider würde ich zu oft sagen, dass ich Unternehmen gesehen habe, in denen sie nicht genug Zeit auf die Governance-Seite verwenden, um zum Beispiel das CICD zu verstehen, weil sie denken, dass dies nicht wichtig ist. Aber stattdessen können Sie für Micro-Frontends, wie für Microservices, mit Automatisierungsrechten die Entwicklung beschleunigen. Wenn Sie nicht genügend Zeit für die Automatisierung aufwenden, riskieren Sie, mehr Belastung als Nutzen zu haben.

Drew: Ich denke, es ist wie bei so vielen Dingen in der Welt der Webentwicklung, wo Leute Gefahr laufen, sich mit einer technischen Lösung zu beschäftigen, bevor sie das Problem wirklich verstanden haben. Und es hört sich so an, als müssten Sie bei Micro-Frontend das Problem sehen und dann die Lösung implementieren, um zu wissen, welches Problem Sie lösen. Ich denke, die Natur des Micro-Frontends macht es sehr einfach, mit der Integration in eine bestehende Anwendung zu beginnen, ein kleines Problem zu erkennen und es durch ein Micro-Frontend auszutauschen, um dieses Problem zu lösen. Ist das ein vernünftiger Vorschlag?

Luca: Ja, das würde ich sagen. In diesem Fall würde ich vorschlagen, wenn wir auf diese Weise beginnen, mehr auf das vertikale Slicing als auf das horizontale Slicing zu achten, da Sie sonst so viele Probleme lösen müssen, nehmen wir an, Sie verwenden Angular und Sie möchten zu einer neuen Version von Angular wechseln. Wenn Sie zwei Angular-Versionen zusammenleben lassen müssen, ohne I-Frame zu verwenden, könnte dies kompliziert oder sogar unmöglich sein. Wenn Sie also anfangen, sehen Sie sich den Aspekt nicht an … wenn Sie die Herausforderung prüfen, nicht aus technischer Sicht, sondern aus betriebswirtschaftlicher Sicht. Vielleicht können Sie zum Beispiel, ich weiß nicht, den Anmeldeteil nehmen, an dem Sie mit einer anderen Version oder derselben Version schreiben möchten, aber einer aktualisierten Version eines Frameworks, und das könnte ein guter Weg sein. Und dann routen Sie durch den Pfad. Das könnte eine gute Möglichkeit sein, eine bestimmte Anwendung langsam aber stetig zu ersetzen.

Luca: Was wir in unserem Fall getan haben, ist im Grunde das Anwenden des Strangler-Musters, das ein bekanntes Muster für Microservices ist, aber auf das Frontend. Also basierend auf der URL und basierend auf dem Browser und dem Land des Benutzers. So langsam aber stetig, im Grunde töteten wir den Monolithen, der in diesem Fall eine Single-Page-Anwendung war, veröffentlichten unsere neue Anwendung öfter und sahen das Verhalten der Benutzer, wenn es die Erfahrung verbesserte, verursachte es irgendein Problem auf unserem System oder nicht. Und das ermöglichte es uns, dem Unternehmen einen unmittelbaren Mehrwert zu bieten, aber gleichzeitig unsere Annahmen zu testen und zu sehen, ob wir in die richtige Richtung gingen oder nicht.

Drew: Es klingt nach einer sehr attraktiven Lösung für einige Probleme, mit denen sicher viele Menschen konfrontiert sind. Wenn ich als Entwickler anfangen wollte, mehr über Micro-Frontend zu recherchieren, wo wäre ein guter Ausgangspunkt?

Luca: Ja, also verbringe ich derzeit einen Großteil meiner Freizeit damit, mich für diese Architektur einzusetzen, weil ich denke, dass es viele Missverständnisse gibt. Auf meinem Medium-Konto. Ich habe mehrere Artikel geschrieben, die dort ebenfalls verfügbar sind. Ich habe viele Videos in Konferenzen aufgenommen, die Sie problemlos auf YouTube finden können. Und die andere Sache, die ich vorschlagen würde, wenn Sie nach einem Codebeispiel für einige Frameworks suchen, das, das ich für den Anfang empfehlen würde, ist ein einzelnes SPA, hauptsächlich weil es einen vertikalen Slicing-Ansatz hat, es einfacher ist, es aufzunehmen und Sie können beginnen, die Vorteile dieser Architektur zu verstehen. Dann gibt es viele andere, die verfügbar sind. Before I mentioned Luigi framework, as well as many others that are currently out there that are allowing you to compose multiple Micro-frontends in the same view.

Luca: Like another one in my head is TailorJS is another interesting. But definitely there is open components that is one developed by Open Table. But in general there are plenty of opportunity if you start to search about Micro-frontend, they're out there.

Drew: That sounds great. Is there anything else that you wanted to talk about with regard to the Micro-frontends?

Luca: Yeah. Personally I would suggest to take an open mind approach on learning this architecture and this approach, technical approach, mainly because I believe that there is a lot of good, but we need to, let's say, invest a bit of time and spend a bit of time to deeply understand how the things are working. Because obviously there isn't, just one way to do things. We are used that we take a framework and immediately we start to work on it and it's super productive, if you think about that.

Luca: But in this case you need to spend a bit of more time understanding, as you said a couple of times, the problem. Understand which is the pattern that would allow you to express better not only from a technical point of view but those two from our organizational point of view, the solution that you have in mind.

Drew: So I've been learning all about Micro-frontend today. What have you been learning about lately?

Luca: Recently there are two things that I'm learning. So last week I was in Las Vegas during the AWS event and is obviously a cloud conference. Pretty amazing, 70,000 people, a lot of sessions that were spreading several hotels in Vegas. And there for me, a serverless is a paradigm that I'm studying the most because I truly believe that in the future that will be the way how we are going to design and implement software and obviously AWS is very prominent on this approach.

Luca: And the second topic is around management and how to be a leader of a tech team. Because obviously I'm SVP of architecture. I have a team of architects that I'm leading and you can never rest because you need to not only to be on top of the technical side, but you need also to understand the people problems, understand how you can make them successful. Because obviously if they are successful, you are successful. You are first a technical facilitator to a certain extent. So that for me, those for me are the two things that currently I'm studying on top of exploring the Micro-frontend world.

Drew: If you, dear listener, would like to hear more from Luca, you can follow him on Twitter where he's @LucaMezzalira or find his activities collected together at Lucamezzalira.com. Thanks for joining us today, Luca. Did you have any parting words?

Luca: No, but thank you very much for listening up to now.