Die Reise zu Micro-Frontends: Herausforderungen und Lösungen

Im Zuge der Umstellung unseres Unternehmens hin zu unabhängigen Micro-Frontends haben sich unsere Teams auf die spannende Reise begeben, die monolithische Struktur zu durchbrechen und ihre eigenen Micro-Frontends zu entwickeln. Die Idee, dass jedes Team seine Micro-Frontend-App mit seinen Bereitstellungsprozessen besitzt, war verlockend und versprach, die Vorlaufzeit zu verkürzen. Wie bei jeder Reise ins Paradies mussten jedoch Herausforderungen auftreten.

Aus dem Monolithen ausbrechen

Der Übergang begann reibungslos. Wir haben ein neues Repositorium erstellt und aus dem Monolith geklont. Ein netter kleiner Trick, um den Git-Verlauf beim Neustarten beizubehalten, besteht darin, deinen Monolithen zu klonen und dann DELETE, DELETE, DELETE.

Hebelwirkung die Single-Spa-Architektur, die wir verwenden, wir haben unseren Kunden wie folgt im Client-Hub registriert:

{
    name: '@floqast/checklist-client',
    activeWhen: '/checklist',
}

Unvorhergesehene Herausforderungen

Aber dann kamen die Hindernisse. Beim Ausbruch stellten wir fest, dass die Ordnerseite als zentraler Punkt diente, an dem zusammengefasste Informationen von anderen Seiten existierten. Dort befanden sich unsere Komponenten (der Checklistenbereich und das Checklisten-Slideout), die alle niedlich herumhingen, und wir mussten den Checklistenabschnitt und das Slideout exportieren, damit sie Teil der Ordnerseite waren, wie unten gezeigt.

Mikrofrontend-übergreifende Importe zulassen

Unsere Architektur basiert auf einem einzigen Spa, und dank ihrer ausgezeichneten Dokumentation, wir haben herausgefunden, dass unser Kunde, solange er im Client-Hub registriert ist, immer für jedes aktive Micro-Frontend verfügbar ist, auch wenn die Checklistenseite nicht aktiv ist. Auf diese Weise können wir den Checklistenabschnitt und das Checklisten-Slideout importieren, wenn wir uns auf der Ordnerseite befinden. Folgendes haben wir getan:

Exportieren

Exportieren Sie den Checklistenabschnitt und die Checklisten-Slideout-Container in die Single-Spa-Entry-Datei des Checklisten-Clients, sodass der Monolith darauf zugreifen kann.

export { ClosePageChecklistSectionV2, ClosePageChecklistSlideOutV2 } from './exports/ChecklistClientContainers';

Konfiguriere

Konfigurieren Sie den Checklisten-Client als externes Webpack im Monolith.

config.externals = ['react', 'react-dom', 'styled-components', '@floqast/header-nav', '@floqast/checklist-client'];

Importiere

Importieren Sie die Container aus dem Checklist-Client in die Ordnerseite.

import { ClosePageChecklistSectionV2, ClosePageChecklistSlideOutV2, setEnv } from '@floqast/checklist-client';

Verwaltung des Staates

Während die Microfrontends voneinander entkoppelt sind, wird der Status für jeden der Clients separat verwaltet. Für die Checklistenseite war es ziemlich einfach, wann Checklisten-Client war der einzige aktive Kunde. Dies wurde auf der Ordnerseite etwas knifflig, da jeder Client verlangte, dass der Redux-Status mit den Daten gefüllt wird, um ihn wie erwartet zu rendern.

Um den Status für die Komponenten verfügbar zu machen, die aus importiert wurden Checklisten-Client, der exportierte Checklistenabschnitt und die Slideout-Container werden mit dem umwickelt <Provider> Komponenten- und API-Aufrufe werden bei der Initialisierung getätigt, um den Speicher mit Daten zu füllen.

Kommunikation zwischen den Micro-Frontends

Wenn bestimmte Änderungen oder Aktionen auf der Ordnerseite vorgenommen werden, müssen diese zwischen den beiden Clients kommuniziert werden. Dies wird mithilfe von Requisiten und Ereignissen gehandhabt.

Überreichende Requisiten

Alle Änderungen auf der Ordnerseite werden an die Checklisten-Client durch Requisiten, die vom Monolithen weitergegeben werden, was dazu führt, dass der Checklistenabschnitt die Checklistenelemente erneut rendert und erneut abruft.

Event-Handling verwenden

Jede Aktion, die im Abschnitt „Checkliste“ ausgeführt wird und von der Seite „Ordner“ abhängt, wird als Ereignisse in ausgegeben Checklisten-Client und vom Monolithen gehört, wie in der Abbildung unten dargestellt, um zu zeigen, wie die Interaktion abläuft.

Fazit

Puh! Obwohl der Weg holprig und voller Herausforderungen war, führte dies dazu, dass unser Team nicht nur aus dem Monolithen ausbrach, sondern auch mehr Kontrolle über unseren eigenen Bereich erlangte und gleichzeitig die Geschwindigkeit erhöhte, mit der wir die Produktion aufnehmen konnten. Dabei lernte unser Team die Feinheiten der Micro-Frontend-Architektur kennen und der Umgang mit unvorhergesehenen Herausforderungen führte dazu, dass unser Team stärker und besser als zuvor hervorging! Geh KERBEROS!