Micro-Frontends Seguros: Magia de Autenticación en Dutch Railways

Hola, voy a hablar sobre los Microfrontends, la magia de la autenticación en los ferrocarriles holandeses. El índice de contenidos, primero paso a los Microfrontends. Te muestro nuestra aplicación final y también nuestros problemas que tuvimos en el pasado. También explico Model Federation, el framework que usamos para Microfrontends, y también la autenticación OIDC. Y finalmente, hablo sobre la configuración de Kubernetes.

Durante la charla, muestro algunas demostraciones en vivo. Soy Pieter Eigenmans. Soy un arquitecto de códigos en Surpasteria. Soy un desarrollador full stack, pero ahora principalmente enfocado en Frontend. El contexto del que estamos hablando hoy, esta charla es sobre Poel y los ferrocarriles holandeses. Poel es una empresa que es responsable de mantener las vías y mantener las estaciones en los Países Bajos. Y también, los ferrocarriles holandeses son responsables de conducir los trenes, operar los trenes, y también vender boletos, por ejemplo.

El nuevo SporeViewer que quiero mostrarte ahora. Hemos creado un hermoso SporeViewer. Esta es nuestra aplicación final. Puedes ver que podemos seguir los trenes en todos los Países Bajos. Esto es Utrecht. También podemos ir a Ámsterdam o Róterdam, o Ámsterdam Central, por ejemplo.

Y podemos seguir todos los trenes aquí, todos los datos en tiempo real, todos los datos en tiempo real. Y estos datos, usamos web sockets para esto. Así que lo que está aquí, ves que se está moviendo aquí y partes de color verde. Así que va en esta dirección. Podemos mostrarte todo, puedes mostrar en la pantalla, muchas intersecciones y también muchas, es una aplicación de vista. Y también podemos cargar, cargar también otra aplicación en la pantalla sobre programación y el oficial de programación de una cierta estación.

Así que también puedes seleccionar aquí otras estaciones y Rotterdam, por ejemplo. Y lo que es tan genial de esta aplicación, que podemos cargar aquí múltiples aplicaciones en la misma pantalla y aún así mantener el rendimiento. Entonces, ¿cómo hacemos esto? Te mostraré, te mostraré diseños.

Lo siento. Añadir aplicación.

Y podemos cargarlo tanto como quieras en la pantalla. Y puedes imaginar que no funcionará normalmente porque es demasiado pesado cargar tales aplicaciones, instancias o aplicaciones múltiples veces. Pero funciona para nosotros. Entonces, ¿cómo hicimos eso? Así que eso es también una de las cosas en nuestra charla. Y también estoy hablando de autenticación. Así que también puedes imaginar cuando abrimos tantos archivos, cómo es posible que podamos iniciar sesión una vez y no cien veces para todas esas aplicaciones que tenemos aquí en la pantalla.

Así que también puedo aquí seleccionar aquí Amersfoort. Así que reconoces un poco cómo funciona. Hay muchas aplicaciones. Y aquí hay otra aplicación para planificación. Así que esta es una aplicación bastante interesante que debería hacerse más grande. BAMFAC, esto es para mostrar las vías del tren entre estaciones. Así que puedes imaginar que es bastante pesado. Aquí ves otra pestaña donde hemos organizado todas esas aplicaciones. Aquí hay una aplicación de planificación. También hemos creado un número de vía. Y también podemos ver que un tren ha reservado un lugar en esta vía a una cierta hora. Y otro tren también ha reservado otro lugar en la vía. Así que aplicaciones bastante interesantes. Y también muy críticas para la misión. Porque cuando esta aplicación no funciona, en una hora todos los trenes se detendrán en Holanda.

Así que sigamos adelante. Ahora conoces un poco el contexto. Así que nuestra aplicación también se acelera muy bien. Así que estamos muy contentos con ello. Pero, ¿cómo hicimos eso? ¿Y cómo gestionamos la autenticación? Ahora tenemos con una nueva aplicación un front-end más rápido. Y también los equipos trabajan muy bien juntos. Así que los equipos no se pisan los talones unos a otros. Entonces, ¿cómo hicimos eso? Mantenimiento más fácil y escalado es posible en esta aplicación. Ciclos de retroalimentación más rápidos.

¿Cómo hicimos eso? Así que primero, eso se ve genial. Vamos a retroceder a 2019. Hola, aquí está Petra. Y ella es la controladora de trenes en 2019. Y tenía muchos problemas cuando intentaba iniciar sesión. Esto es realmente un monolito. Y sí, ella sigue siendo un monolito en 2019. Y queremos dividirlo. Pero vemos aquí que tenemos un gran problema también con la carga en tiempo real de la aplicación. También la autenticación fue bastante difícil en un cierto momento. Y también las pantallas dejaron de cargar en un cierto día en una cierta mañana. Y ella estaba muy frustrada. Dos horas más tarde en la estación de Ámsterdam, hubo mucho caos. 3,000 trabajadores ferroviarios bloqueados. El sistema de autenticación se cayó. Y sí, era realmente hora punta. Así que es un hermoso, fue un hermoso desastre, el monolito. No es mantenible, porque cuando quieres agregar o eliminar algo en esta aplicación, cuesta mucho tiempo. Y cuando hay un problema en una parte de la aplicación, también puede afectar a otra parte de la aplicación. Así que no queremos eso, por supuesto, más. Desarrollo lento, puedes imaginar, una base de código enorme, también demasiado grande para desplegar. Toma mucho tiempo desplegar. Y también un único punto de fallo, puedes imaginar. Y difícil de escalar. No puedes escalarlo muy bien. No es mantenible.

Así que no puedes agregar y eliminar partes o aplicaciones fácilmente. Entonces, ¿qué pasaría si pudiéramos, sí, sí, ir de un monolito a una velocidad modular? ¿Cómo, si queremos hacer eso, tenemos que desplegar características independientemente y dejar que los equipos se muevan rápido. Así que sin pisarse los talones unos a otros.

Conectar múltiples aplicaciones sin problemas y usar multifederation como marco para compartir código y escalar. También, queremos iniciar sesión una vez, no para cada mosaico en nuestra pantalla queremos iniciar sesión por separado. Queremos iniciar sesión una vez en toda esta aplicación. Entonces, ¿cómo hicimos eso?

¿Cómo compartimos un estado de aplicación en todas las aplicaciones y cómo refrescar tokens y asegurar web sockets para datos en tiempo real. Vamos más allá. Arquitectura de monolito a velocidad modular. Primero, tenemos que dividir nuestras aplicaciones de front y back end. Y luego dividimos nuestro back end en microservicios, puedes imaginar, por supuesto. Y luego queremos dividir nuestra aplicación en verticales. Usamos diseño dirigido por el dominio para eso. Y no estoy hablando de eso ahora, pero está bien, puedes imaginar que el equipo A es responsable de un caso de negocio y el equipo B de otro caso de negocio. Y ves que cada vertical de front y back end se comunica con el otro a través de eventos.

Y también el front y el back end se comunican entre sí a través de endpoints rest o web sockets en nuestra aplicación. Vemos aquí algo interesante que el front y el back end están emparejados entre sí. Y reconozco aquí un patrón arquitectónico, y ese es este patrón. Un estilo arquitectónico está aquí donde aplicaciones de front y back end entregables independientemente se componen en un muro mayor. Y eso es lo que Martin Fuller dijo.

Y eso es lo que Martin Fuller dijo. Y eso es también la definición de micro front ends. Micro front ends no es solo sobre front end, así que puedes decir, pero también puedes decir que es también sobre back end. Eso es interesante. Y no es micro en absoluto, así que la palabra no es buena.

Micro front ends. Micro front ends al rescate. Arquitectura de micro front ends. Pasamos de verticales a arquitectura de micro front ends para los ferrocarriles holandeses. Dividimos nuestro back end en microservicios. Dividimos nuestro front end de la misma manera.

Y para la arquitectura de micro front ends, siempre tenemos una aplicación host o shell. Como dice la definición, compone el front y el back end juntos. Así que esa es también la definición de micro front ends. Y usamos el host o el shell. Y el host y el shell son responsables de la composición de enrutamiento del front end y el back end, autenticación, autorización, gestión de estado, escalado. Así que puedes fácilmente añadir o eliminar partes de los micro front ends a través de la aplicación host shell. Así que esta es nuestra primera configuración arquitectónica.

Ves que nuestra aplicación contiene un host o un shell. Puede ser una aplicación enorme con una gran base de código. El host y el shell son bastante para nuestra aplicación. Nuestro host es bastante grande. También aquí con la aplicación principal de seguimiento de trenes y la planificación de rutas y tenemos una sección de vías y muchas más aplicaciones que tenemos ahora.

¿Cómo construir el frontend de manera eficiente? Sí, usamos module federation para eso. Es un framework. Es un framework para hacer que todo esto suceda. Pero vamos un poco más allá en el tiempo. En 2022 comenzamos con Web Components. Usamos nuestro nuevo modelo arquitectónico. Pero también usamos Web Components.

Y aún tenemos problemas de carga porque para cada mosaico en la pantalla, puedes imaginar, React también se carga. Así que React se carga múltiples veces. Y también nuestras bibliotecas compartidas pueden ser cualquier biblioteca de JavaScript como load dash o también se cargan múltiples veces. Así que la aplicación todavía era muy lenta, un poco más rápida que el monolito. Pero aún demasiado lenta para Petra.

Así que en 2025 usamos model federation para la velocidad. ¿Y qué vemos aquí? Que con model federation, eso es lo grande. Carga React una vez y también las bibliotecas compartidas se cargan una vez para todos esos mosaicos en la pantalla. Así que esa es la noticia que quiero traer. Cada micro frontend tiene su propio pipeline CI-CD. Y también, sí, puedes escalar la aplicación bastante fácilmente. Puedes añadir y eliminar nuevos micro frontends con bastante facilidad. Y también agnóstico, eso significa que también puedes mezclar diferentes frameworks de frontend en una configuración de module federation. Así que también puedes hacer seguimiento de trenes. La aplicación de infraestructura puede construirse en Angular. La gestión de rutas puede construirse en React. Y la sección de vías puede construirse en Vue. Así que nuestra aplicación es muy eficiente.

¿Cómo configurar? Sí, el host y el shell y los remotos que tenemos, esos dos roles que tenemos. El remoto representa nuestro micro frontend, que también tiene su propia configuración y el host y el shell. Entonces, ¿cómo se ve la configuración? Parece que tenemos la configuración del host y el shell y vemos que requerimos una dependencia de federación nativa. Y esto es todo lo que necesitamos. Tenemos que definir el nombre del host. Lo llamamos host aquí por simplicidad y también qué dependencias queremos compartir. Y lo hago aquí con una sola línea, compartir todo. Y omitir, eso significa que todas esas dependencias que se definen aquí no se comparten con el host y el remoto.

La aplicación remota es un poco lo mismo. Parece que también hay un nombre. Y expone su aplicación principal al host a través de la sección de exposiciones. Así que también en la parte de compartir, definimos lo que queremos compartir con el host. Y compartimos todo y omitimos algunas. Pero también podemos configurar versiones específicas. Podemos definir versiones específicas para compartir con el host. Así que ves aquí la misma configuración. Lo que queremos exponer, expuesto a nuestra aplicación host. Ese es el archivo app.tsx. Y en la parte de compartir definimos que queremos cargar React como un singleton. Así que se cargará una vez. Eso es muy importante para acelerar la aplicación. Y también que necesitamos una versión requerida, una cierta versión, que queremos compartir.

Así que esto es, hemos alcanzado nuestros primeros objetivos. Podemos desplegar características independientemente con MultiFederation. Y dejamos que los equipos se muevan rápido. Ya no nos pisamos los talones unos a otros con esta configuración. Podemos conectar múltiples aplicaciones y también usar MultiFederation para compartir código y escalar fácilmente. Ahora envuelve este código y ve a MultiFederation con React. Autenticación. Demos un paso más allá.

También puedes tomar este código. MultiAppAuthenticationNightmare. Sí, puedes imaginar que tuvimos este problema con todos esos mosaicos que tenemos, bucles relacionados con la lectura, y también problemas de curso y múltiples inicios de sesión. Así que tenemos dos héroes de la autenticación moderna. Tenemos un open id connect, OIDC. Esa es nuestra capa de identidad. OIDC es como mostrar tu ID en la entrada de un concierto, por ejemplo. Y también Oout es como obtener una pulsera de festival. Los actores clave en esta historia son el servidor de autenticación. Lo llamamos EntraID porque usamos Microsoft para ello. Así que lo llaman EntraID en Microsoft. Y ese es el debouncer. Así que muestras tu boleto y obtienes tu pulsera. El servidor de recursos es otro actor clave. Ese es tu API. Y también puedes imaginar que es el camarero. Él verifica si tienes que tienes tu pulsera. Y también el cliente mismo, la aplicación React.

Bien, ¿cómo funciona un flujo OIDC? Usamos Microsoft Authentication Library para esto. Y maneja muchas cosas de este flujo. Pero en general, el flujo es el siguiente. Inicio de sesión y autorización inicial. Así que primero necesitamos una configuración de Microsoft. Y la configuración de Microsoft consiste en un client ID, que representa el ID de la aplicación en Microsoft EntraID. Y authority, que contiene la URL del servidor de autenticación. Aquí, este es uno de los participantes. Bien. Y también redirige la URL de tus lectores de tu aplicación cuando quieres iniciar sesión. Y también he definido algunas subpartes. Cuando queremos solicitar inicio de sesión.

También defino aquí mi alcance. Cuando inicio sesión, uso un alcance. ¿Qué tipo de permisos tienes para iniciar sesión? Y también, puedes definir otras partes. Defino aquí recursos protegidos. Entonces, ¿qué URLs están protegidas por Microsoft Authentication Library?

Bien. Tenemos esta configuración y es importante comenzar con el inicio de sesión. Así que el usuario inicia sesión. Y luego el paso dos, iniciar sesión con el redireccionamiento de inicio de sesión. Vamos a EntraID. Y el EntraID verifica tu configuración de MSAL con tu client ID y tu authority y tu directorio. Cuando eso está bien, obtienes una página de inicio de sesión y luego ingresas tu nombre de usuario, contraseña, y luego obtienes de vuelta tu código de autorización. Eso es interesante. Código de autorización que obtienes de vuelta.

Ahora puedes obtener algo más. Regresas con el código de autorización. La biblioteca MSAL puede manejarlo por ti, puede darte los tokens. Los tokens para obtener datos, para extraer datos de tu base de datos, por ejemplo. Bien, primero tienes que obtener los tokens. Y el EntraID devuelve tus tokens basados en el código de autorización que das. Y los tokens pueden ser un token de acceso, un token de ID y un token de actualización.

Así que te explico un poco más tarde cuáles son las diferencias con estos. Y luego obtienes tus tokens de vuelta. Y ahora, cuando tienes los tokens, puedes hacer llamadas a la API. Así que primero, queremos obtener datos de la base de datos.

Así que solicitamos datos. Y también obtenemos el token de acceso de la biblioteca MSAL que ya tenemos. Y verificamos si el token de acceso ha expirado. Cuando ha expirado, el token de actualización devolverá automáticamente un nuevo token de acceso para ti.

Y en nuestra aplicación, cada media hora, obtenemos un nuevo token de acceso de nuestra biblioteca MSAL. Así que cuando haces una llamada a la API, el token de acceso también se añade a la llamada a la API. Así que la magia es que Microsoft Application Library inyecta el token a través de interceptores HTTP.

Entonces, cuando has añadido eso, puedes obtener tus datos. Así que vamos a este simple ejemplo de inyección de tokens MSAL. Inyección de tokens. Sí, eso significa, por ejemplo, que tienes un componente UMP, y un usuario quiere obtener una bebida. Los interceptores HTTP añadirán automáticamente un token bearer, lo llaman, o un token de acceso, que es lo mismo, a la URL. Y luego puedes obtener tu bebida, por ejemplo. Bueno, también puede ser datos. Y esto es lo que MSAL hace por ti bajo el capó.

Y el token bearer es también como tu pulsera. El flujo es en resumen, inicio de sesión, el usuario inicia sesión, a través de enter ID, obtiene un código de autorización, y a través del código de autorización, obtiene directamente tres tokens, el token de acceso para hacer llamadas a la API, un token de usuario, o token de ID para información del usuario y un token de actualización para actualizar tu token de acceso. Y también el token de actualización es también para inicio de sesión único. Y también, podemos usar todos esos, sí, el token de acceso, podemos usarlo para hacer llamadas a la API y resolver para OADC. ¿Cómo hacemos esto en código?

Tienes que instalar las bibliotecas MSAL, componentes de inicio de sesión del mundo real, cómo hacer que un contexto MSAL esté disponible para todos los componentes. Ahora, puedes ver que importamos React, importamos MSAL provider, etc. Pero también importamos la aplicación cliente pública. Y eso es importante para envolver el, para obtener la instancia MSAL. ¿Cómo hacemos eso? Hacemos nueva aplicación cliente pública, y pasamos en la configuración MSAL, ya lo sabes. Y con la instancia MSAL, puedes crear un contexto MSAL. Y dentro de este contexto, puedes trabajar con todos esos componentes que tienes en un contexto MSAL. Así que cada otro, cada componente ahora es seguro, puedes decir, a través de MSAL. Construye tu primer componente de botones de aplicación.

Parece un poco difícil, pero no lo es. Tenemos un use MSAL que importamos aquí. Y eso es para obtener la instancia de la, lo que ya hemos creado aquí, la instancia MSAL. Podemos obtener eso de este, use MSAL hook. Plantilla de aplicación y una plantilla de aplicación. Esto solo es necesario para mostrar datos en la pantalla cuando estás conectado o desconectado. Así que aquí, primero, obtenemos aquí la instancia. ¿Y qué podemos hacer con la instancia? Podemos manejar la instancia de inicio de sesión, dot login redirect. Y con la instancia, podemos cerrar sesión. Y en la plantilla, podemos mostrar, tú muestras los botones de cerrar sesión basados en si estás conectado o iniciar sesión cuando no estás conectado. Y también puedes usar estos botones de aplicación, por supuesto, en otro componente, no hay problema. Y también puedes usar estas etiquetas nuevamente para ver si estás conectado, etc.

Protegiendo rutas o páginas con plantilla de aplicación MSAL. Plantilla protegiendo páginas. Así que ahora importamos la plantilla de aplicación MSAL es un poco diferente. Estas plantillas de aplicación MSAL activan un inicio de sesión si el usuario no está conectado. Así que eso es, y luego cuando está conectado, entonces puedes ir a los datos del perfil. Así que tenemos un poco estos esenciales, esenciales MSAL para React. Tenemos la plantilla autenticada que muestra contenido solo si está conectado, solo se usa para UI condicional. Y tenemos la plantilla de aplicación MSAL que muestra contenido y activa el inicio de sesión si es necesario. Así que para proteger páginas completas y usar el hook use MSAL da acceso a tu instancia MSAL, tus cuentas y tu estado. Así que esto es todo lo que necesitas para construir y trabajar con MSAL. Así que no es tan difícil.

¿Cómo compartimos la autenticación a través de micro frontends? Así que ahora hemos autenticado solo nuestra aplicación host con esta configuración. Queremos también autenticar también nuestros micro frontends. Ahora todavía tenemos este problema, iniciar sesión aquí, iniciar sesión allí, diferentes estados de inicio de sesión en cada aplicación. Queremos tener un inicio de sesión único, por supuesto. La solución es muy simple. Compartir paquetes MSAL a través de la federación de modelos. Lo ves que lo hacemos en un host.

Compartimos esos dos paquetes, dependencias como singletons, MSAL Angular, MSAL, React como un error tipográfico, MSAL browser como un singleton. Y también cargamos aquí en el sitio remoto, esos paquetes. Y luego la federación de modelos también cargará el paquete MSAL una vez.

Bien, un pequeño resumen sobre WebSockets para datos en tiempo real. Usamos eso para mostrar los trenes en la pantalla. Así que para WebSockets, tienes que, hay un nuevo protocolo de red y es para comunicación bidireccional. Para configurarlo, tienes que hacer una solicitud de apretón de manos inicial y luego permanece abierto y ya no se necesita reconexión y los datos se envían desde el backend al frontend. Así que es lo que quieres, por supuesto, pero tenemos un desafío aquí. Los WebSockets no soportan encabezados HTTP para tokens.

Entonces, ¿cómo resolvimos esto? La solución es el manejo de autorización personalizada. Así que obtenemos el token a través de los métodos acquire token silent de la instancia. Y luego podemos colocarlo en un campo de protocolo y luego podemos agregar el protocolo a WebSockets a través de nuevos WebSockets.

También puedo mostrar un poco aquí, aquí tenemos nuestra aplicación. Puedo cerrar sesión. Y lo siento. Sí, sí. Ya tenemos como dos minutos de grabación. ¿Qué dices? Ya tenemos 30 minutos de grabación. Ya, está bien. Tengo que parar ahora. Sí, ya casi termino. Así que bien, comencemos de nuevo esta aplicación. Aquí inicio sesión de nuevo. Está bien, no importa. Comencemos. ¿Deberíamos continuar desde aquí? Sí.

Bien. El desafío final es una configuración de Kubernetes. Queremos tener una aplicación para muchos entornos. Así que aquí tenemos una configuración. Esta es esta configuración de nuestro config. Ya sabes, y está colocada en nuestra aplicación. Y esto no es lo que queremos. Así que lo colocamos en Kubernetes en una configuración de Kubernetes. Y a través de config map, podemos cargar nuestro archivo de configuración basado en el entorno en el que estamos ejecutando. Así que puedo mostrarte un poco de código.

Bien, y luego está aquí tenemos una configuración de Kubernetes con la aplicación base. Y por entorno, tenemos una aceptación producción, tenemos una configuración, tenemos un archivo de configuración. Y a través de este YAML, tenemos un generador de config map donde podemos reemplazar nuestro archivo de configuración. Así que recogerá el archivo de configuración correcto en el entorno correcto. Así que el config map de Kubernetes proporciona la configuración de la aplicación por entorno, y luego la aplicación carga el archivo de configuración, podemos inyectarlo con inyección de dependencias. Y finalmente, la configuración puede ser utilizada en la aplicación. Así que una aplicación en diferentes entornos, las configuraciones se almacenan en Kubernetes, y para cambiar la configuración, podemos cambiarla sin reconstruir la aplicación. Sí, cambiar la configuración, podemos cambiarla sin reconstruir la aplicación. Así que recuerda a Petra, ella está muy feliz. Y reclama un día mundial, prueba la multifederación e implementa AMP solve para flujos OADC sin problemas. Gracias.