Saltar al contenido principal

Aspectos que deben tenerse en cuenta sobre el uso de microfrontends

Rendimiento de renderizado de microfrontends​

Los microfrontends a menudo incluyen flujos de aplicaciones completos y pueden requerir nuevos montajes o renderizaciones innecesarios de sus componentes principales. En React, cuando se vuelve a montar un componente principal, se reconstruye el árbol de React que le corresponde.

Si bien los componentes pequeños pueden controlar la repetición de los montajes o de las renderizaciones principales rápidamente, es posible que este no sea el caso para una aplicación completa. Por lo tanto, asegúrese de que el componente principal donde coloque el microfrontend sea estable en términos de rendimiento de renderizado. De esta manera, su microfrontend no vuelve a renderizar innecesariamente todo su árbol.

Para identificar problemas de renderizado en los componentes principales de microfrontend, puede utilizar la pestaña Generador de perfiles en Herramientas para el desarrollador de React.

Las aplicaciones de microfrontend son resilientes a las renderizaciones en la aplicación shell.

Cuándo usar el archivo index.js​

El archivo index.js solo se utiliza cuando la aplicación se usa en modo independiente, ya que no se pasa ningún mfeData. Cuando el microfrontend está incrustado, el shell llama a la función startApp para obtener mfeData relevante y se ignora al archivo index.js.

Autenticación de microfrontends​

Cuando la integración de autenticación está habilitada, el shell administra el ciclo de vida del token, lo que proporciona una mejor experiencia para el usuario. Deshabilitar la integración de la autenticación resulta en flujos de autenticación separados para el shell y los microfrontends, y cada uno utiliza tokens independientes. Tenga en cuenta que los microfrontends con uso compartido de contexto no pueden tener una autenticación independiente cuando la integración está deshabilitada.

En la siguiente tabla, se muestra la compatibilidad para cada situación (MFE es la sigla de microfrontend):

SituaciónComponente MicroFrontend con uso compartido del contexto (modo compartido)Componente MicroFrontend con aislamiento de contexto (modo aislado)SDK de microfrontend
Integración habilitada, tanto el shell como el MFE tienen autenticaciónSíSíSí
Integración deshabilitada, tanto el shell como el MFE tienen autenticaciónNoSíSí
Integración deshabilitada, solo el shell tiene autenticaciónSíSíSí
Integración deshabilitada, solo el MFE tiene autenticaciónNoSíSí

Cuando la aplicación shell es una aplicación de confianza de JDP que se puede integrar con Guidewire Hub para obtener un token de autenticación, la aplicación shell puede pasar este token al microfrontend sin problemas. Esto crea una experiencia de usuario fluida en la que el proceso de autenticación es transparente para el usuario después de iniciar sesión en la aplicación shell.

Para las aplicaciones shell que no sean de Jutro, si la aplicación shell es una aplicación de confianza, por ejemplo, una aplicación propiedad de la organización, y puede integrarse con Guidewire Hub para obtener un token de autenticación, por ejemplo, mediante OIDC, también puede pasar este token al microfrontend. Esta situación también da como resultado una experiencia de usuario fluida, similar a la de las aplicaciones de Jutro, donde el flujo de autenticación es invisible para el usuario después del inicio de sesión.

Si la aplicación shell no es de confianza, por ejemplo, se trata de un portal de terceros que no es propiedad de la organización o si no puede integrarse con Guidewire Hub para obtener un token de autenticación, el microfrontend debe iniciar el flujo de autenticación de forma independiente. En este caso, el microfrontend debe obtener el token de autenticación de Guidewire Hub por sí mismo, lo que normalmente resulta en una experiencia de usuario que no es la óptima, ya que se le pedirá al usuario que inicie sesión a través de una ventana emergente para obtener el token web JSON necesario.

Note: Puede existir una situación en la que un microfrontend tenga auth habilitado y el shell tenga auth deshabilitado. En este caso, el microfrontend abre una ventana emergente cuando usted intenta iniciar sesión.

En la ventana emergente, hay dos opciones:

  • Permisos otorgados. Volver a cargar. Este botón habilita las ventanas emergentes en el navegador y vuelve a cargar el microfrontend. Esta opción permanece hasta que usted cambie la configuración de su navegador.

  • Abrir manualmente. Este botón le permite abrir la pantalla de inicio de sesión manualmente. Esta opción aparecerá cada vez que un microfrontend requiera un inicio de sesión.

Botones de permiso

Renovación pasiva de tokens de microfrontends​

La renovación pasiva de tokens se introdujo en la versión 10.10. La renovación activa no quedó obsoleta, pero se recomienda pasar a la renovación pasiva. Para habilitar esta función, debe realizar los siguientes pasos:

  1. Elimine las variables JUTRO_AUTH_SILENT_REDIRECT_PATH y JUTRO_AUTH_SILENT_LOGIN_PATH, si están presentes. Estas variables son específicas del método activo con inicio de sesión silencioso y no son necesarias para el método pasivo.
  2. Agregue offline_access a la variable JUTRO_AUTH_SCOPE.
  3. Asegúrese de que la configuración de la aplicación Guidewire Hub incluya la concesión REFRESH_TOKEN en su matriz authSettings.grantTypes.
  4. Agregue la variable JUTRO_AUTH_USE_PASSIVE_TOKEN_RENEWALS=true.
  5. Reemplace los siguientes usos de propiedades desde el gancho useAuth:
Renovación activaRenovación pasiva
isAuthenticated: boolean | nullgetIsAuthenticated: () => Promise<boolean | null>
accessToken: string | nullgetAccessToken: () => Promise<string | null>
idToken: string | nullgetIdToken: () => Promise<string | null>
userInfo: OidcUserInfo | nullgetUserInfo: () => Promise<OidcUserInfo | null>

La renovación pasiva de tokens se puede habilitar por shell o microfrontend. Sin embargo, es importante que tenga en cuenta las siguientes situaciones en las que el método de renovación de tokens difiere entre el shell y cualquiera de sus microfrontends:

  • El shell controla el ciclo de vida del token. Si el shell tiene habilitada la renovación activa de tokens, entonces cualquier microfrontend con renovación pasiva de tokens habilitada funcionará como si la renovación activa estuviera habilitada.
  • Si el shell tiene habilitada la renovación pasiva de tokens, todos los microfrontends también deben tener habilitada la renovación pasiva de tokens. Por lo tanto, todos los microfrontends deben migrar al método de renovación pasiva antes de migrar el shell.

Sesiones persistentes de microfrontend con el SDK de Digital​

Cuando se utiliza un microfrontend con el SDK de Digital, se genera un encabezado de autenticación al inicializar el SDK. Esto puede causar problemas en entornos agrupados si un usuario tiene que navegar entre el microfrontend y la aplicación shell, ya que los usuarios podrían terminar obteniendo datos obsoletos de un nodo diferente.

Hay un parámetro enableStickySession en las funciones de inicialización del SDK de Digital, pero este parámetro no funciona como se espera en este escenario. Para asegurarse de que un shell y un microfrontend utilicen los mismos encabezados de sesión persistentes, debe crear un gancho de React personalizado que utilice interceptores Axios para aplicar un encabezado constante.

El siguiente fragmento de código proporciona una solución alternativa de gancho de React de ejemplo para este problema:

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]);
}

Para utilizar esta solución alternativa, agregue una llamada a useStickySession en su archivo App.tsx, después de ejecutar la función de inicialización del SDK de Digital con enableStickySession establecido en false.

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

    initPcSdkJutro({
        enableStickySession: false,
    });

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

   ...
}

Algoritmo de resolución CSS de microfrontends​

Las aplicaciones de microfrontend agregan una clase de encapsulador para cada regla CSS durante la compilación. Esto le permite a usted modificar los estilos del microfrontend fácilmente. Los nombres de las clases de encapsuladores se leen desde mfeAppId que está establecido en la variable JUTRO_APP_ID en el archivo .env de la aplicación o el campo webpack.moduleFederation.name en el archivo overrides.config.js de la aplicación. Este ID se utiliza como cssScope. Esta regla no se aplica al tema y el estilo invalida fileURLToPaths. Si esta configuración no existe, no se agrega la clase de encapsulador.

Por ejemplo, si un módulo CSS se define como .appHeader {...}, se transformaría en .mfeAppId . app_App_appHeader {...} en el conjunto de salida. La aplicación shell conoce el nombre del microfrontend incrustado, por eso, agrega .mfeAppId al contenedor donde se renderiza el microfrontend.

Invalidación de estilos predeterminados de Jutro​

Desde Jutro 10.0, todos los componentes de Jutro en aplicaciones de microfrontend han aumentado la especificidad de los selectores de estilo. Por ejemplo, jut__Button__button ahora es .mfeAppId .jut__Button__button.

Note: El valor appName proviene del valor establecido en webpack.moduleFederation.name en el archivo overrides.config.js.

El mfeAppId del microfrontend proviene de webpack.moduleFederation.name en el archivo overrides.config.js, a menos que se haya establecido JUTRO_APP_ID.

Esto sucede con todas las aplicaciones expuestas como microfrontends, independientemente de si se consumen a través de la federación de módulos, iframe, el SDK de microfrontends de Jutro o si se accede a ellas directamente como aplicación independiente. Esto tampoco es configurable.

Este requisito es para los clientes que todavía usan styleOverrides.css, y es necesario para invalidar los estilos predeterminados de Jutro. styleOverrides.css es un mecanismo de tematización más antiguo, y ya no se recomienda su uso.

Asignación de nombre a su microfrontend​

Cuando cree un microfrontend, defina un appName en el método start(). Esto no es algo específico de los microfrontends. El appName se define en todas las aplicaciones de Jutro y se utiliza para varias funciones. Para obtener más información sobre appName y para qué se utiliza, consulte la documentación sobre configuración global .

Configuración del ID de aplicación de su microfrontend​

Cuando crea un microfrontend, también debe establecer un ID de aplicación único para él. Este ID de aplicación se puede definir en uno de estos dos lugares:

  • Desde la variable JUTRO_APP_ID en su archivo .env.
  • Desde webpack.moduleFederation.name en overrides.config.js.

Este ID único de la aplicación se utiliza para varios propósitos:

  • Se utiliza como prefijo para todas las clases CSS y los componentes personalizados en el microfrontend.
  • Se utiliza para identificar el microfrontend cuando está incrustado en una aplicación shell.
Warning: Es importante asignar a cada microfrontend un ID único. Al incrustar varios microfrontends en aplicaciones shell, si dos microfrontends comparten el mismo ID, las aplicaciones se interrumpirán.

Cuando incrusta un microfrontend, el ID se establece utilizando la variable JUTRO_APP_ID en su archivo .env o moduleFederation.name en su archivo overrides.config.js. Si ambas están definidas, la variable JUTRO_APP_ID tiene prioridad. Luego, el ID de la aplicación se utiliza como prefijo para todas las clases CSS y los componentes personalizados en el microfrontend, así como el identificador del microfrontend. Sin embargo, a diferencia de appName, el JUTRO_APP_ID no se proporciona al usuario final en ninguna parte.

Este ID de aplicación también se utiliza cuando se llama al microfrontend. Por ejemplo, si incrusta el microfrontend mediante el componente MicroFrontend, la declaración del componente se vería así:

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

Variable de entorno de orden de carga​

La variable de entorno JUTRO_NEW_CONFIG_LOADING_ORDER no afecta a los microfrontends si se establece en los archivos de configuración de la aplicación shell. Solo afecta a la aplicación en la que se configuró. Sin embargo, se puede configurar para afectar al microfrontend desde la aplicación shell pasando la variable de entorno dentro de la propiedad configOverrides al llamar al microfrontend:

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

Al configurar el orden de carga para el microfrontend, se puede configurar en el archivo .env o en el archivo config.json. Las configuraciones de la aplicación shell no pueden afectar a la configuración del archivo .env del microfrontend, solo a la del archivo config.json.

El valor del orden de carga se verifica en dos ubicaciones:

  • Cuando las configuraciones se cargan inicialmente, el valor process.env se verifica primero. Si JUTRO_NEW_CONFIG_LOADING_ORDER no se establece en true en el archivo .env, se registra la siguiente advertencia:

Está utilizando el orden de carga de la configuración anterior. Las variables definidas en su archivo .env tendrán prioridad sobre las variables utilizadas en loadConfiguration(...). Para habilitar el nuevo orden de carga de la configuración, agregue JUTRO_NEW_CONFIG_LOADING_ORDER=true a su archivo .env.

  • En cada llamada getConfigValue, para determinar el orden. Cuando se produce esta comprobación, primero se verifica config.json, luego, si no se encuentra ningún valor, se verifica el valor process.env.

Eso significa que si la aplicación shell pasa JUTRO_NEW_CONFIG_LOADING_ORDER: true, el microfrontend debe usar el nuevo orden de configuración, pero la advertencia sigue apareciendo de todos modos. Lo contrario también ocurre, si el microfrontend tiene habilitado el nuevo orden de carga, la aplicación shell puede forzar la deshabilitación y no habrá advertencias en este caso. Para eliminar esta advertencia, la variable de orden de carga se debe establecer en true en el archivo .env del microfrontend.

Para obtener más información acerca de JUTRO_NEW_CONFIG_LOADING_ORDER, consulte la página Configuración global.