Ü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)	MicroFrontend 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, für das die Organisation nicht zuständig ist oder das nicht in Guidewire Hub integriert werden kann, 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 auth für ein Micro Frontend aktiviert ist, auth für die Shell 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 abgekündigt, 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 Erneuerung	Passive Erneuerung
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.

Sticky Sessions für Micro Frontends mit dem Digital SDK

Bei Verwendung eines Micro Frontends mit dem Digital SDK wird bei der Initialisierung des SDK ein Authentifizierungs-Header generiert. Dies kann in Cluster-Umgebungen zu Problemen führen, wenn ein Benutzer zwischen dem Micro Frontend und der Shell-App navigiert, da Benutzer möglicherweise veraltete Daten von einem anderen Knoten erhalten.

Es gibt einen enableStickySession-Parameter in den Initialisierungsfunktionen des Digital SDK, der in diesem Szenario jedoch nicht wie erwartet funktioniert. Um sicherzustellen, dass eine Shell und ein Micro Frontend dieselben Sticky-Session-Header verwenden, müssen Sie einen benutzerdefinierten React-Hook erstellen, der Axios-Interceptors verwendet, um einen konstanten Header anzuwenden.

Das folgende Codefragment bietet ein Beispiel für ein React-Hook-Workaround für dieses Problem:

import { useEffect } from 'react';
import { isNil } from 'lodash';
import { getSdkConfig } from 'src/generated/PcSdk';
import { getFromSessionStorage, setInSessionStorage } from '../utils';

type AxiosRestService = ReturnType<typeof getSdkConfig>['restService'];

type useStickySessionProps = {
  restService: AxiosRestService;
};

export function useStickySession(props: useStickySessionProps): void {
  useEffect(() => {
    let sessionId = getFromSessionStorage('stickySessionId');

    if (isNil(sessionId)) {
      sessionId = crypto.randomUUID();
      setInSessionStorage('stickySessionId', sessionId);
    }

    props.restService.axiosInterceptors.request.use((config) => {
      const correlationId = crypto.randomUUID();

      return {
        ...config,
        headers: {
          ...config.headers,
          'x-gwre-session': sessionId,
          'x-correlation-id': correlationId,
        },
      };
    });
  }, [props.restService]);
}

Um dieses Workaround zu verwenden, fügen Sie einen Aufruf in useStickySession in Ihrer App.tsx-Datei hinzu, nachderm Sie die Initialisierungsfunktion des Digital SDK mit der auf false gesetzten enableStickySession-Eigenschaft ausgeführt haben.

App.tsx

export const AppRoot: React.FC = (): JSX.Element => {
    ...

    initPcSdkJutro({
        enableStickySession: false,
    });

    useStickySession({ restService: getPcSdkConfig().restService });

   ...
}

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 im Ausgabebündel zu .mfeAppId . app_App_appHeader {...} 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. 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.

Die 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 dessen Verwendungszweck finden Sie in der Dokumentation zur globalen Konfiguration.

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 .env-Datei.
• 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:

Sie verwenden die alte Ladereihenfolge der Konfigurationen. Variablen, die in Ihrer Datei .env definiert sind, haben Vorrang vor Variablen, die in loadConfiguration(...) verwendet werden. Um die neue Konfigurationsladereihenfolge zu aktivieren, fügen Sie JUTRO_NEW_CONFIG_LOADING_ORDER=true zu Ihrer Datei .env hinzu.

• 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.