Überlegungen zur Verwendung von Micro Frontends

Rendering-Leistung von Micro Frontends

Micro Frontends enthalten oft komplette Anwendungsabläufe und reagieren empfindlich auf unnötiges erneutes Mounting oder erneutes Rendering ihrer übergeordneten Komponenten. Wenn in React eine übergeordnete Komponente neu gemountet wird, wird der React-Baum darunter neu aufgebaut.

Während kleine Komponenten übergeordnete Neueinbindungen oder Neurenderungen schnell verarbeiten können, ist dies möglicherweise nicht für eine gesamte Anwendung der Fall. Stellen Sie also sicher, dass die übergeordnete Komponente, in der Sie Ihr Micro Frontend platzieren, in Bezug auf die Rendering-Leistung stabil ist. Auf diese Weise rendert Ihr Micro Frontend nicht unnötigerweise seine gesamte Struktur neu.

Um Rendering-Probleme in übergeordneten Micro Frontend-Komponenten zu identifizieren, können Sie die Registerkarte „Profiler“ in den React Developer Tools verwenden.

Die Micro Frontend-Apps sind resistent gegen das Rendern in der Shell-App.

Verwendung der Datei „index.js“

Die Datei index.js wird nur verwendet, wenn die App im eigenständigen Modus verwendet wird, da kein mfeData übergeben wird. Wenn das Micro Frontend eingebettet ist, ruft die Shell die Funktion startApp auf, um das relevante mfeData zu erhalten und die Datei index.js wird ignoriert.

Authentifizierung von Micro Frontends

Wenn die Authentifizierungsintegration aktiviert ist, verwaltet die Shell den Tokenlebenszyklus und bietet so eine bessere Benutzererfahrung. Das Deaktivieren der Authentifizierungsintegration führt zu getrennten Authentifizierungsabläufen für die Shell und die Micro Frontends, wobei beide unabhängige Token verwenden. Beachten Sie, dass Micro Frontends mit gemeinsamem Kontext keine unabhängige Authentifizierung aufweisen können, wenn die Integration deaktiviert ist.

Die folgende Tabelle zeigt die Kompatibilität für jedes Szenario:

Szenario	MicroFrontend-Komponente mit Kontextfreigabe (Freigabemodus)	MicroFrontend-Komponente mit Kontextisolierung (isolierter Modus)	Micro Frontend SDK
Integration aktiviert, Shell und MFE verfügen über Authentifizierung	Ja	Ja	Ja
Integration deaktiviert, Shell und MFE verfügen über Authentifizierung	Nein	Ja	Ja
Integration deaktiviert, nur Shell verfügt über Authentifizierung	Ja	Ja	Ja
Integration deaktiviert, nur MFE verfügt über Authentifizierung	Nein	Ja	Ja

Wenn die Shell-App eine vertrauenswürdige JDP-Anwendung ist, die in Guidewire Hub integriert werden kann, um ein Authentifizierungstoken zu erhalten, kann die Shell-App dieses Token nahtlos an das Micro Frontend übergeben. Dies schafft eine reibungslose Benutzererfahrung, bei der der Authentifizierungsprozess für den Benutzer nach der Anmeldung über die Shell-App transparent ist.

Für Nicht-Jutro-Shell-Apps gilt: Wenn die Shell-App eine vertrauenswürdige Anwendung ist, z. B. eine App im Besitz der Organisation, und in Guidewire Hub integriert werden kann, um ein Authentifizierungstoken zu erhalten, z. B. mithilfe von OIDC, kann sie dieses Token auch an das Micro Frontend übergeben. Dieses Szenario führt auch zu einer reibungslosen Benutzererfahrung, ähnlich wie in Jutro-Apps, bei der der Authentifizierungsablauf für den Benutzer nach der Anmeldung unsichtbar ist.

Ist die Shell-App nicht vertrauenswürdig, beispielsweise handelt es sich um ein Drittanbieterportal, das die Organisation nicht besitzt, oder kann nicht in Guidewire Hub integriert werden, um ein Authentifizierungstoken zu erhalten, muss das Micro Frontend den Authentifizierungsablauf unabhängig initiieren. In diesem Szenario muss das Micro Frontend das Guidewire Hub-Authentifizierungstoken selbst abrufen, was in der Regel zu einer suboptimalen Benutzererfahrung führt, da der Benutzer über ein Popup-Fenster aufgefordert wird, sich anzumelden, um das erforderliche JSON Web Token zu erhalten.

Note: Es kann ein Szenario geben, in dem für ein Micro Frontend auth aktiviert ist, für die Shell auth jedoch deaktiviert ist. In diesem Fall öffnet das Micro Frontend ein Popup-Fenster, wenn Sie versuchen, sich anzumelden.

Im Popup-Fenster gibt es zwei Optionen:

• Berechtigung ** erteilt. Neu laden:** Diese Schaltfläche aktiviert Popups im Browser und lädt das Micro Frontend neu. Diese Option bleibt bestehen, bis Sie Ihre Browsereinstellungen ändern.

• Manuell öffnen: Mit dieser Schaltfläche können Sie das Anmeldefenster manuell öffnen. Diese Option wird jedes Mal angezeigt, wenn ein Micro Frontend eine Anmeldung erfordert.

Passive Token-Erneuerung für Micro Frontends

Die passive Token-Erneuerung wurde in Version 10.10 eingeführt. Die aktive Erneuerung wird nicht verworfen, es wird jedoch empfohlen, zur passiven Erneuerung zu wechseln. Um diese Funktion zu aktivieren, müssen Sie die folgenden Schritte ausführen:

1. Entfernen Sie die Variablen JUTRO_AUTH_SILENT_REDIRECT_PATH und JUTRO_AUTH_SILENT_LOGIN_PATH (falls vorhanden). Diese Variablen sind spezifisch für den aktiven Ansatz mit unbeaufsichtigter Anmeldung und werden für den passiven Ansatz nicht benötigt.
2. Fügen Sie offline_access zur Variable JUTRO_AUTH_SCOPE hinzu.
3. Stellen Sie sicher, dass die Guidewire Hub-Anwendungskonfiguration die Berechtigung REFRESH_TOKEN im authSettings.grantTypes-Array enthält.
4. Variable JUTRO_AUTH_USE_PASSIVE_TOKEN_RENEWALS=true hinzufügen.
5. Ersetzen Sie die folgenden Verwendungen von Eigenschaften aus dem useAuth-Hook:

Aktive Verlängerung	Passive Verlängerung
isAuthenticated: boolean | null	getIsAuthenticated: () => Promise<boolean | null>
accessToken: string | null	getAccessToken: () => Promise<string | null>
idToken: string | null	getIdToken: () => Promise<string | null>
userInfo: OidcUserInfo | null	getUserInfo: () => Promise<OidcUserInfo | null>

Die passive Token-Erneuerung kann pro Shell oder Micro Frontend aktiviert werden. Die folgenden Szenarios sind jedoch zu beachten, wenn sich der Ansatz zur Token-Erneuerung zwischen der Shell und einem der zugehörigen Micro Frontends unterscheidet:

• Die Shell steuert den Token-Lebenszyklus. Wenn in der Shell die aktive Token-Erneuerung aktiviert ist, funktionieren alle Micro-Frontends mit aktivierter passiver Token-Erneuerung so, als ob die aktive Token-Erneuerung aktiviert wäre.
• Wenn in der Shell die passive Token-Erneuerung aktiviert ist, muss die passive Token-Erneuerung ebenfalls für alle Micro-Frontends aktiviert sein. Daher müssen alle Micro-Frontends auf den passiven Erneuerungsansatz migriert werden, bevor die Shell migriert wird.

CSS-Auflösungsalgorithmus für Micro Frontends

Micro-Frontend-Apps fügen während des Build-Vorgangs eine Wrapper-Klasse für jede CSS-Regel hinzu. Auf diese Weise können Sie die Stile des Micro-Frontend einfach ändern. Die Namen der Wrapper-Klassen werden aus der mfeAppId gelesen, die in der Variablen JUTRO_APP_ID in der Datei .env der App oder dem Feld webpack.moduleFederation.name in der Datei overrides.config.js der App festgelegt ist. Diese ID wird als cssScope verwendet. Diese Regel gilt nicht für das Theme und der Stil überschreibt fileURLToPaths. Wenn diese Konfiguration nicht vorhanden ist, wird die Wrapper-Klasse nicht hinzugefügt.

Wenn beispielsweise ein CSS-Modul als .appHeader {...} definiert ist, wird es zu .mfeAppId . app_App_appHeader {...} im Ausgabebündel transformiert. Die Shell-App kennt den Namen des eingebetteten Micro-Frontends und fügt daher .mfeAppId dem Container hinzu, in dem das Micro-Frontend gerendert wird.

Überschreiben von Standard-Jutro-Stilen

Seit Jutro 10.0 haben alle Jutro-Komponenten in Micro-Frontend-Anwendungen die Spezifität der Style-Selektoren erhöht. Zum Beispiel jut__Button__button ist jetzt .mfeAppId .jut__Button__button.

Note: Der Wert appName stammt aus dem in webpack.moduleFederation.name in der Datei overrides.config.js festgelegten Wert.

mfeAppId des Micro Frontends stammt aus webpack.moduleFederation.name in der Datei overrides.config.js, es sei denn, JUTRO_APP_ID wurde festgelegt.

Dies gilt für alle Anwendungen, die als Micro Frontends verfügbar gemacht werden, unabhängig davon, ob sie über Modulföderation, iframe, Jutro MicroFrontend SDK oder direkt als eigenständige Anwendung genutzt werden. Dies ist auch nicht konfigurierbar.

Diese Anforderung gilt für Kunden, die noch immer styleOverrides.css verwenden, und dann ist es notwendig, die Standardstile von Jutro zu überschreiben. styleOverrides.css ist ein älterer Theming-Mechanismus, dessen Verwendung nicht mehr empfohlen wird.

Benennen eines Micro Frontends

Wenn Sie ein Micro Frontend erstellen, definieren Sie einen appName in der start()-Methode. Dies ist nicht spezifisch für Micro Frontends. appName ist in allen Jutro-Apps definiert und wird für verschiedene Funktionen verwendet. Weitere Informationen zu appName und der Verwendung finden Sie in der Dokumentation zur globalen Konfiguration der Wrapper-Komponente ApplicationRoot.

Festlegen der App-ID eines Micro Frontends

Wenn Sie ein Micro Frontend erstellen, müssen Sie auch eine zugehörige eindeutige App-ID festlegen. Diese App-ID kann an einer von zwei Stellen definiert werden:

• In der Variable JUTRO_APP_ID in der Datei .env.
• In webpack.moduleFederation.name in overrides.config.js.

Diese eindeutige App-ID wird dann für mehrere Zwecke verwendet:

• Sie wird als Präfix für alle CSS-Klassen und benutzerdefinierten Komponenten im Micro Frontend verwendet.
• Sie wird zum Identifizieren des Micro Frontends verwendet, wenn es in eine Shell-App eingebettet ist.

Warning: Es ist wichtig, jedem Micro Frontend eine eindeutige ID zuzuweisen. Wenn mehrere Micro Frontends in Shell-Apps eingebettet werden und zwei Micro Frontends dieselbe ID haben, führt dies zu einem Ausfall der Apps.

Wenn Sie ein Micro Frontend einbetten, wird die ID über die Variable JUTRO_APP_ID in der Datei .env oder über moduleFederation.name in der Datei overrides.config.js festgelegt. Wenn beide definiert sind, hat die Variable JUTRO_APP_ID Vorrang. Die App-ID wird dann als Präfix für alle CSS-Klassen und benutzerdefinierten Komponenten im Micro Frontend sowie als Kennung des Micro Frontends verwendet. Im Gegensatz zu appName wird JUTRO_APP_ID für Endbenutzer jedoch nirgends zur Verfügung gestellt.

Diese App-ID wird auch verwendet, wenn Sie das Micro Frontend aufrufen. Wenn Sie beispielsweise das Micro Frontend unter Verwendung der MicroFrontend-Komponente einbetten, sieht die Komponentendeklaration wie folgt aus:

<MicroFrontend src="JUTRO_APP_ID_HERE@https://example.com/mfe" ... />

Umgebungsvariable für Ladereihenfolge

Die Umgebungsvariable JUTRO_NEW_CONFIG_LOADING_ORDER wirkt sich nicht auf Micro Frontends aus, wenn sie in den Konfigurationsdateien der Shell-App festgelegt ist. Sie wirkt sich nur auf die App aus, in der sie festgelegt wurde. Sie kann jedoch so konfiguriert werden, dass sie sich auf das Micro Frontend über die Shell-App auswirkt, indem die Umgebungsvariable beim Aufrufen des Micro Frontends in der Eigenschaft configOverrides übergeben wird:

jutro: {
    configOverrides: {
        JUTRO_NEW_CONFIG_LOADING_ORDER: true,
    },
}

Beim Festlegen der Ladereihenfolge für das Micro Frontend kann diese entweder in der Datei .env oder in der Datei config.json festgelegt werden. Die Konfigurationen der Shell-App können sich nicht auf die Einstellungen in der Datei .env des Micro Frontends auswirken, sondern nur auf die Einstellungen in der Datei config.json.

Der Wert der Ladereihenfolge wird an zwei Stellen geprüft:

• Beim ersten Laden der Konfigurationen wird der Wert process.env zuerst geprüft. Wenn JUTRO_NEW_CONFIG_LOADING_ORDER in der Datei true nicht auf .env festgelegt ist, wird die folgende Warnung protokolliert:

You are using the old configuration loading order. Variables defined in your .env file will take precedence over variables used in loadConfiguration(...). To enable the new config loading order, add JUTRO_NEW_CONFIG_LOADING_ORDER=true to your .env file.

• Bei jedem Aufruf von getConfigValue, um die Reihenfolge zu bestimmen. Bei dieser Überprüfung wird zuerst config.json geprüft. Wenn kein Wert gefunden wird, wird dann der Wert process.env geprüft.

Das heißt, wenn die Shell-App JUTRO_NEW_CONFIG_LOADING_ORDER: true übergibt, muss die neue Konfigurationsreihenfolge im Micro Frontend verwendet werden, aber die Warnung wird dennoch angezeigt. Umgekehrt gilt auch: Wenn die neue Ladereihenfolge für das Micro Frontend aktiviert ist, kann die Shell-App die Deaktivierung erzwingen. In diesem Fall wird keine Warnung angezeigt. Zum Entfernen dieser Warnung muss die Variable für die Ladereihenfolge in der Datei .env des Micro Frontends auf true festgelegt werden.

Weitere Informationen zu JUTRO_NEW_CONFIG_LOADING_ORDER finden Sie auf der Seite Globale Konfiguration.