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

Im Zuge der Umstellung unserer Organisation auf unabhängige Mikro-Frontends begaben sich unsere Teams auf die aufregende Reise, aus der monolithischen Struktur auszubrechen und ihre eigenen Mikro-Frontends zu entwickeln. Der Gedanke, dass jedes Team seine eigene Mikro-Frontend-Anwendung mit eigenen Bereitstellungsprozessen besitzt, war verlockend und versprach eine Verkürzung der Vorlaufzeit. Doch wie bei jeder Reise ins Paradies waren auch hier Herausforderungen vorprogrammiert.

Aus dem Monolithen ausbrechen

Der Übergang begann reibungslos. Wir erstellten ein neues Repository und klonten vom Monolithen. Ein netter kleiner Trick, um die Git-Historie zu erhalten, während man neu anfängt, ist, den Monolithen zu klonen und dann LÖSCHEN, LÖSCHEN, LÖSCHEN.

Indem wir die von uns verwendete Single-Spa-Architektur nutzen, haben wir unseren Client im Client-Hub registriert, indem wir Folgendes getan haben:

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

Unvorhergesehene Herausforderungen

Doch dann kamen die Hindernisse. Beim Ausbrechen stellten wir fest, dass die Seite "Ordner" als zentraler Punkt diente, an dem Informationen von anderen Seiten zusammengefasst wurden. Dort befanden sich unsere Komponenten (der Abschnitt "Checkliste" und das "Checklisten-Slideout"), die ganz niedlich herumhingen, und wir mussten den Abschnitt "Checkliste" und das Slideout exportieren, damit sie Teil der Seite "Ordner" wurden, wie unten gezeigt.

Mikro-Frontend-übergreifende Importe zulassen

Unsere Architektur basiert auf Single-Spa, und dank der ausgezeichneten Dokumentation haben wir herausgefunden, dass unser Client, solange er im Client-Hub registriert ist, immer für jedes aktive Mikro-Frontend verfügbar ist, auch wenn die Checklist-Seite nicht aktiv ist. Dies ermöglicht es uns, den Checklistenabschnitt und das Checklisten-Slideout zu importieren, wenn wir uns auf der Seite "Ordner" befinden. So haben wir es gemacht:

Exportieren

Exportieren Sie die Container "Checklist Section" und "Checklist Slideout" innerhalb der Single-Spa-Entry-Datei des Checklisten-Clients, damit der Monolith darauf zugreifen kann.

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

Konfigurieren Sie

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

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

Importieren

Importieren Sie die Container aus dem Checklisten-Client in die Seite "Ordner".

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

Staatliches Management

Während die Mikro-Frontends voneinander entkoppelt sind, wird der Status für jeden der Clients separat verwaltet. Für die Checklistenseite war es ziemlich einfach, als checklist-client der einzige aktive Client war. Dies wurde auf der Seite "Folders" etwas schwierig, da jeder Client den Redux-Zustand mit den Daten auffüllen musste, um sie wie erwartet zu rendern.

Um den Zustand für die Komponenten verfügbar zu machen, die von checklist-clientwerden die exportierten Container Checklist Section und Slideout mit der Option <Provider> Komponente, und bei der Initialisierung werden API-Aufrufe getätigt, um den Speicher mit Daten zu füllen.

Kommunikation zwischen den Mikro-Frontends

Wenn bestimmte Änderungen oder Aktionen auf der Seite "Ordner" vorgenommen werden, müssen diese zwischen den beiden Clients kommuniziert werden. Dies geschieht mit Hilfe von Requisiten und Ereignissen.

Passende Requisiten

Alle Änderungen auf der Seite "Ordner" werden an die checklist-client durch Requisiten, die vom Monolithen nach unten weitergegeben werden, was dazu führt, dass der Abschnitt Checkliste neu gerendert wird und die Checklistenelemente erneut abgerufen werden.

Verwendung der Ereignisbehandlung

Jede Aktion, die im Abschnitt "Checkliste" stattfindet und von der Seite "Ordner" abhängt, wird als Ereignis in checklist-client und vom Monolithen abgehört werden, wie das nachstehende Diagramm zeigt, um zu verdeutlichen, wie die Interaktion stattfindet.

Schlussfolgerung

Puh! Obwohl der Weg holprig und mit Herausforderungen gespickt war, führte er dazu, dass unser Team nicht nur aus dem Monolithen ausbrechen konnte, sondern auch mehr Kontrolle über unseren eigenen Bereich erlangte, während wir gleichzeitig die Geschwindigkeit der Produktionsfreigabe erhöhen konnten. In diesem Prozess lernte unser Team die Feinheiten der Mikro-Frontend-Architektur kennen, und der Umgang mit unvorhergesehenen Herausforderungen führte dazu, dass unser Team stärker und besser als zuvor hervorging! Los KERBEROS!

Zeeshan Qureshi

Zeeshan "Zee" Qureshi ist Software Engineer II bei FloQast und arbeitet an der Entwicklung des Compliance Management Produkts. Wenn es Abend wird, kann man Zee dabei beobachten, wie er sich mit seiner Sammlung von Star Wars-Figuren beschäftigt oder wie er sich vor dem Fernseher vergnügt, auch bekannt als *kritischer* Medienkonsum in großen Mengen.