Utilizando Micro-Frontends Basados en Módulos ES para Habilitar el Desarrollo Distribuido

Buenos días a todos. Con esa cantidad de videos sobre JPMorgan, no hay presión hoy. Como dije, mi nombre es Steve y estoy aquí para hablar un poco sobre cómo estamos utilizando tecnologías web modernas, JP, cosas como los módulos de ES donde podemos usarlos para resolver problemas antiguos, problemas como cómo ejecutar múltiples aplicaciones que han sido construidas e implementadas de forma independiente en aplicaciones tipo portal de contenedor único.

Un poco sobre mí. He estado trabajando en el espacio fintech durante unos 20 años y he tenido el privilegio de ver crecer las tecnologías de interfaz de usuario durante ese tiempo. Y ahora que estoy en JP Morgan, ya no soy un desarrollador principal. Pero ahora trabajo con desarrolladores para armar nuestra oferta de código abierto. Hoy voy a hablar de dos cosas. Una es el UITK, que es una biblioteca de componentes de React que usamos para estandarizar la apariencia y la experiencia de sus aplicaciones. Y Modular, que es una herramienta de gestión de monorepos con opiniones. Ambos están en nuestro Github público, si quieres echarles un vistazo. Y agradecemos las solicitudes de extracción.

Los lugares en los que he trabajado antes, como dije, siempre han sido en Fintech. Algunas de esas organizaciones son realmente pequeñas. Cuando llegué a JP Morgan el año pasado, no tenía una idea real de la escala a la que me iba a enfrentar. En el banco en general, tenemos 50,000 desarrolladores, creo. 18,000 de ellos están en nuestra división. Y estamos implementando alrededor de 5,800 aplicaciones en uno de nuestros tipos de contenedor, que es un contenedor de escritorio. 2,000 de ellas están en producción. Sirven a unos 200,000 usuarios diarios. Hay cientos de implementaciones todos los días. Tenemos este problema de desarrollo realmente distribuido. O alegría, dependiendo de cómo lo veas. El desarrollo distribuido significa que tenemos muchos equipos de desarrollo. Todos trabajan de forma independiente. Tienen la libertad de tomar sus propias decisiones sobre cómo van a construir sus aplicaciones, cómo las van a implementar y, más recientemente, con qué frecuencia las implementan. ¿Por qué están enviando código en realidad? Pero desde un punto de vista organizativo, ¿cuál es la experiencia del desarrollador de ese modelo de desarrollo distribuido? Bueno, cada equipo de desarrollo tiene que resolver los mismos problemas. Todos van a necesitar alguna forma de integración continua. Todos van a necesitar implementación continua, y todos van a tener la misma necesidad de aplicar aseguramiento de calidad. Por lo tanto, van a necesitar herramientas de prueba. Van a necesitar elegir los mismos productos para realizar sus pruebas.

Y luego, debido a que todos estamos bajo la misma marca, necesitaremos tener el mismo lenguaje de diseño. Entonces, ¿cómo agregamos esa consistencia a las aplicaciones que estamos implementando? Teniendo en cuenta que hay miles de ellas siendo lanzadas. Entonces, cuando las aplicaciones se implementan, también necesitarán resolver el mismo tipo de problemas. Necesitamos saber cómo autenticar a sus usuarios, cómo autorizarlos para usar las aplicaciones. Y debido a que queremos tener las mismas experiencias de usuario ricas, estamos pensando cómo podrás compartir los diseños que has creado, cómo podrás compartir el acceso a tus aplicaciones. Lo cual implica que tienes el mismo tipo de comprensión de tener un sistema de preferencias. Cómo almacenarás y persistirás los datos del usuario.

Entonces, ¿cuál fue nuestra solución para eso? Nuestra solución está en la ingeniería de UI. Tenemos lo que llamamos la Plataforma Digital, que es algo así como un proveedor de Jamstack dentro del banco. Ya mencioné que tenemos un contenedor de escritorio, pero también tenemos formas en las que distribuimos nuestras aplicaciones móviles y web. Lo llamamos Omnicanal, pero también proporcionamos más un enfoque de DevOps. Entonces, tenemos cosas como integración continua, en realidad está basado en Jenkins. Tenemos implementación continua que se basa en Amazon S3. Y también proporcionamos un registro de aplicaciones centralizado y ahí es donde nuestros desarrolladores envían las versiones de su código para que podamos determinar cuáles estarán disponibles en producción. Y lo más importante, cuando necesitamos revertir las cosas, simplifica nuestros procesos. Y luego, probablemente más relevante para hoy y de lo que voy a hablar más adelante es que tenemos un sistema de diseño. Es un sistema de diseño que prioriza la accesibilidad y que tiene una biblioteca de componentes basada en React. Hemos adoptado los componentes web y permitimos el uso de Angular. Se tomó una decisión hace un par de años de que nos enfocaríamos en React. De hecho, tenemos una nueva versión de la biblioteca de React que se está desarrollando en este momento. Se lanzará muy pronto. Siéntete libre de ir a verlo en nuestro GitHub. Y finalmente, el Modular, que es una herramienta de gestión de monorepos con opiniones. Tiene algunas características que mostraré hoy, pero es similar a create-react-app y tiene una opinión sobre las herramientas de desarrollo que se utilizan para construir las aplicaciones en sí.

Tenemos un contenedor de escritorio. Los desarrolladores, cuando crean aplicaciones, las envían a nuestra infraestructura de implementación continua y le dicen al contenedor de escritorio, que es una aplicación basada en Electron, dónde buscar las URL. Cuando llegamos a entregar un portal web, ¿cuál es la expectativa de la experiencia del usuario? En realidad, es casi lo mismo que en el escritorio. Los usuarios aún quieren tener una forma única de lanzar aplicaciones. Quieren tener una apariencia y experiencia consistentes en las aplicaciones que cargan, y quieren poder usar sus aplicaciones en todos los navegadores modernos. Históricamente, eso podría haber significado usar iframes para cargar aplicaciones juntas, lo que conlleva las desventajas habituales de tener muchos, potencialmente muchos, instancias de frameworks cargados en una aplicación, en una ventana del navegador web.

Cuando se utiliza memoria, las cosas se vuelven inestables. No se puede compartir o compartir fácilmente CSS y temas entre las diversas aplicaciones que se han cargado. Entonces, ¿cuál fue nuestra solución? Bueno, mencioné que estamos utilizando tecnologías modernas, por lo que ahora nos estamos enfocando en tener micro front-ends. Los micro front-ends en los que estamos enfocados se basan en módulos ES para dividir las aplicaciones y cargarlas de forma dinámica. Y la biblioteca React que hemos creado utiliza variables CSS para compartir temas en las diversas aplicaciones que podrías estar cargando.

Esto tiene muchos beneficios. Cosas como, si estás utilizando módulos ES, la forma en que transpilaremos nuestras aplicaciones es tomando el código fuente, generalmente en TypeScript, reescribir las importaciones que están en tu propia aplicación para agrupar el código de tu aplicación por separado, y luego reescribir todas tus dependencias externas en un CDN. Utilizamos un CDN de código abierto para módulos ES, ESM.SH, échale un vistazo, es genial, pero también puedes estar utilizando Skypack. De hecho, tenemos versiones internas de estos que pueden acceder y transpilar nuestros módulos de nodo Commons.js existentes en nuestro registro interno a módulos ES. En caso de que no estés familiarizado, los módulos ES, son un estándar actual y moderno para crear JavaScript en su forma más simple, probablemente ya los estés utilizando en TypeScript, y es una forma conveniente de simplemente tener tus importaciones y exportaciones en tu código después de que se haya transpilado a JavaScript.

La otra cosa es que tenemos un contenedor de aplicaciones web. Dejamos de admitir Internet Explorer en el último año más o menos. Realmente no lamentamos su pérdida, porque significa que ahora podemos usar navegadores actualizados, todos los cuales pueden admitir la carga dinámica de importaciones en JavaScript sin necesidad de complementos adicionales.

Bien, entonces, construyendo un micro frontend. Eso fue mucho de mí. Es hora de la demostración en vivo, que obviamente nunca sale mal, así que por favor ten paciencia conmigo.

Entonces, he mencionado, oh, bien. He mencionado modular. Tiene una forma de crear aplicaciones. Está basado en algo muy similar a tu aplicación React creada, sin embargo, lo que estamos viendo aquí, voy a usar esto, es un monorepo mínimo. Tiene algunos paquetes hasta ahora. Un paquete es simplemente un servidor express que simula el registro de aplicaciones del que hablé antes, va a servir nuestro contenido construido, para que puedas ver la demostración. Y también tenemos un ejemplo de cómo crear una aplicación principal.

Ahora, la aplicación React creada sería capaz de servir estos componentes, por lo que se ve muy similar a lo normal, utilizando Webpack y el servidor de desarrollo de Webpack. Recientemente, cambiamos a Webpack 5 y agregamos soporte para la construcción de ES. Con la construcción de ES, en lugar de generar un paquete commons.js, ahora creamos un paquete de módulo ES. Entonces, lo que voy a hacer aquí es ejecutar un comando rápido para, ahí vamos, iniciar un servidor express. También va a iniciar un servidor de desarrollo de Webpack. Debería, ahí vamos, bien. Va a cargar muy lentamente en localhost. Mi aplicación, vamos a asumir que es así. Volveré a eso más tarde.

Luego, otras cosas que tiene modular. Ahora, mencioné esta entrega de desarrollo a gran escala. A menudo, a gran escala, tenemos la necesidad de crear nuevas aplicaciones y esas nuevas aplicaciones se crean a partir de plantillas. Entonces, modular tiene una función que puede usar plantillas basadas en, que vienen directamente de NPM o desde tus repositorios. Así que voy a usarlas, vienen de mi repositorio. Entonces, voy a agregar un nuevo módulo a mi monorepo. Voy a ver la tarjeta. Ah, estoy, ahí vamos, No puedo escribir con la gente mirándome. Entonces, usando los comandos de modular para agregar un nuevo paquete a mi plantilla, ya he creado algunas plantillas, pero solo para que veas cómo se agregan. ¿Por qué estoy pasando por esto? Las plantillas que agregamos en realidad se pueden ejecutar como aplicaciones independientes. Entonces, en la vista de código, ahora tengo una nueva aplicación.

No hace mucho. Afortunadamente, no usa useReact, sino useEffect. Oh, ¿lo hace? ¿Es ese uno efectivo? Tal vez, bueno, finjamos que no has visto mis useEffects, dije que ya no hago código para vivir, y ahora que eso ha creado un nuevo paquete, puedo empezar a usarlo para mí mismo. Voy a empezar a usar un nuevo puerto.

Entonces, digamos que voy a ejecutar esta aplicación. Lo que esto está haciendo es actuar como proxy si un desarrollador está creando la aplicación para sí mismo, ¿cargó la antigua? ¿Hola? ¿Hola? Ahí vamos. Estos sí cargan. Bueno. Si no carga, voy a hablar un poco más y luego te mostraré el video porque las demostraciones en vivo hacen eso. Bien. Bien. De todos modos, supongamos que puedes renderizarlos. No importa. 3000, 2001. Sabes, nunca he visto que create React app se detenga. Bien, sabía que no debería haber intentado hacer una demostración en vivo.

De acuerdo, así que voy a seguir por ahora y luego te mostraré el video y será increíble. Voy a agregar otro. Bien, intentando de nuevo. Luego, a continuación, tendré que hablar un poco. ¿Empieza? Bien. Bien, bien. ¿Quién querría que funcione directamente desde el principio, eh? No importa. De acuerdo, ¿de qué voy a hablar? La idea es que tenemos esta vista de tarjeta. En realidad, se renderizan como aplicaciones independientes que puedes instalar con yarn. Lo siento, puedes empezar con Webpack DevServer. El siguiente paso es, después de haber creado un par de paquetes, mostrar cómo se ejecutan juntos. Entonces, a continuación, tendría que construirlos. Ahora, la diferencia en el proceso de construcción es que al ejecutarlo a través de esbuild, estamos, ah. Al ejecutarlo a través de esbuild, en realidad creamos un módulo ES, que es un solo archivo que luego se puede cargar en un CDN.

En el ejemplo que tengo aquí, en realidad se ejecuta como un servidor local, y veamos si ha funcionado su magia a través de Internet. Bueno, resulta que no estoy en línea. Qué lástima. Porque lo he estilizado desde que creé este video. Decepcionante. Bueno, puedes ver lo que estaba haciendo ayer. Así que supongamos que esto se está ejecutando en vivo.

Voy a ver por qué mis módulos no se están cargando desde Internet y tal vez si vienes a encontrarme, puedo mostrarte una versión real en funcionamiento de esto, como puedes ver en todos los videos. Tenemos un puesto afuera. Estaré allí más tarde con una versión funcional. Pero te mostraré la versión simulada en su lugar.

Así que aquí tenemos la misma ventana de código donde hice un yarn serve. Esto iniciará mi servidor de nodos, que es como el proxy para nuestro registro de aplicaciones y configura un create React app. Hasta ahora no hay nada en la pantalla porque lo que necesito hacer es agregar uno de esos componentes. Esto te muestra cómo construí uno de esos, ejecuté ES build y al ejecutar ES build, generé mi módulo ES que luego se carga en el CDN. Aquí puedes ver, si lo hemos cargado usando nuestro portal, en realidad eso es algo que puedo mostrarte, este es un archivo JavaScript que se carga dinámicamente.

¿Cómo lo hicimos? En el paquete principal, creé una vista remota. La vista remota es en realidad un componente muy simple que simplemente obtiene un módulo desde una URL. Ese módulo, obviamente, comparte su estado a través de un contexto para asegurarnos de no intentar cargar estos módulos varias veces. Aquí puedes ver cómo estamos cargando realmente la vista remota. Esa carga utiliza JavaScript que se ejecuta nativamente en el navegador. No necesitamos ningún complemento para hacer esto. Simplemente tenemos una solicitud desde nuestro manifiesto. En realidad, usamos el package JSON para definir el contenido que describe el módulo. Usamos eso, en realidad puedo mostrarte uno de esos, lo usamos para describir cómo se ha construido el módulo. Así que puedes ver que incluye algunos paquetes, ese es nuestro sistema de diseño. Pero también, ¿dónde está la salida del JavaScript y el CSS? Esos luego serán utilizados por esta vista remota para decir, cuando obtengamos ese package JSON, entonces sabemos si tenemos una hoja de estilo, podemos insertarla en el HTML. Esa puede que no sea la mejor manera de hacerlo, pero funcionó. Y si tenemos un manifiesto, este es donde hemos puesto el JavaScript. Observa esa importación dinámica, eso es compatible nativamente en todos los navegadores.

Si estás ejecutando esto a través de Webpack, necesitarás una pequeña escapatoria, porque Webpack intentará evaluar la declaración de importación por ti. Pero sabiendo que hemos hecho una importación dinámica en el navegador, eso nos da el contenido predeterminado evaluado del paquete en sí. Así que sabemos que esos serán nuestras vistas. Simplemente usamos esa vista como un constructor de componentes y podemos incluirla en el TypeScript TSX.

Presumo que aún no estoy en línea. OK. La siguiente parte es que puedo agregar más. Puedo agregar más componentes a esto, construyéndolos de forma independiente. Y luego podemos usar el portal, simplemente porque realiza una carga dinámica. El portal se implementa de forma independiente de las aplicaciones que contiene. Y luego, en mi demostración de trabajo real, estaba tan orgulloso, tenía la cuadrícula y la tarjeta hablando entre sí. Pero ahí vamos. Tengo un ejemplo que puedo compartir que muestra esto en funcionamiento. Es algo muy simple de poner en marcha. Creo que eso fue acercándome al tiempo. Así que me quedaba por decir que, al cargar los modules en el mismo árbol de React, podemos beneficiarnos de cosas como el intercambio de modules, el intercambio de dependencias, especialmente si tienes dependencias con estado. Comparten la misma instancia. Por lo tanto, tenemos un sistema que recomienda que los desarrolladores de nuestra aplicación fijen al menos React a la misma versión, lo cual simplemente usa el objeto de resoluciones en un package.json que luego usamos la misma versión de React en todas nuestras aplicaciones. Y sí, nuestras compilaciones son más rápidas porque solo tenemos que compilar y transpilar nuestro propio código de aplicación. Reducen el tamaño del archivo que almacenamos en nuestro CDN. Se cargan más rápido en el navegador porque comparten dependencias entre ellos. Y sí, estoy realmente emocionado de que podamos usar tecnología moderna para resolver problemas que han existido durante mucho tiempo. Así que disculpen si la demostración no funcionó muy bien. Pero honestamente, ven a verme más tarde y realmente funciona. Genial. Gracias. Gracias. Gracias. Oh, qué placer. Por favor, cariño mío, siéntate en el asiento caliente.

Gracias. Vamos a hablar un poco sobre modular, lo cual es una gran alegría para mí. En primer lugar, buen trabajo teniendo una copia de seguridad del video. Es un consejo de orador profesional porque la conexión Wi-Fi en las conferencias generalmente no es buena debido a la gran cantidad de personas. Así que buen trabajo. Uf. Lo sé.

Ya tenemos un par de preguntas en Slido. Recuerden, slide.do y el código es 2124. Vamos a la pregunta en vivo. ¿Cómo gestionan las implementaciones de estas aplicaciones distribuidas? ¿Simplemente implementan paquetes ESM? ¿Qué sucede cuando necesitan sincronizar las implementaciones de múltiples aplicaciones? Ah, divertido. Depende del equipo. Tenemos, como mencioné antes, equipos de desarrollo que no se conocen entre sí. A veces, cuando tenemos cosas interconectadas, utilizamos una variación de Scrum of Scrums, para poder planificar juntos. Hay grandes programas de trabajo. Estos programas generalmente involucran a los líderes técnicos de las aplicaciones que se van a implementar, a sus gerentes de producto, para poder dar forma a cómo se van a implementar. Las implementaciones en sí utilizan una variedad de tecnologías. Estaba hablando de las más nuevas y brillantes. Algunas de ellas son aplicaciones en contenedores. Algunas de ellas son totalmente independientes de otras aplicaciones. El CDN que mencioné es bastante nuevo. Con ese, tratamos cada versión como inmutable, por lo que incluso en nuestra implementación continua cada compilación que sale de CI se envía al CDN y, por lo tanto, está disponible para su uso como una aplicación en producción. Así que sí, tenemos muchas aplicaciones que dependen entre sí. Depende del contacto humano. Tenemos que hablar entre nosotros para saber cuándo podemos implementarlas, realmente. ¡Qué concepto tan novedoso!

Lo sé, ¿verdad? Tengo una pregunta sobre las opiniones de Modular. Estuve presente cuando se creó Modular hace algún tiempo. Y no sé cómo se ve ahora. Pero recuerdo que el concepto era que iba a ser muy opinativo. Lo mencionaste.

¿Qué parte de tener un creador de aplicaciones muy opinativo ha funcionado para ustedes, ha funcionado a gran escala y puede o no funcionar para alguien que no tenga tantas aplicaciones? Así que ha funcionado de alguna manera. Cuando se usó al principio, realmente se trataba de iniciar nuevas aplicaciones. En el cambiante mundo del desarrollo de UI, era conveniente tener una forma consistente de elegir herramientas o configurar la configuración para sus herramientas. El espacio de desarrollo de UI se mueve muy rápido. Entonces, lo que era confuso y difícil en ese momento no necesariamente es confuso y difícil ahora. Si bien modular existe como una forma de estandarizar cómo interactuamos con aplicaciones, se está volviendo cada vez menos opinativo. Por lo tanto, hay cada vez más formas de escape para acompañarlo. Y en realidad, nos brinda una forma realmente única de ayudar a escalar el desarrollo. Ahora no solo estamos en el origen de las aplicaciones. Ahora estamos siendo incluidos en aplicaciones a gran escala que desean agregar nuevas características. Cosas como las nuevas versiones de, creo que lo llamamos ghost testing, para ejecutar pruebas solo en las cosas que han cambiado en su solicitud de extracción o en las cosas que dependen de usted. Y pronto tendremos la compilación incremental de solo construir selectivamente. Por lo tanto, se agrega.

Eso se relaciona con otra pregunta que tenemos, ¿cómo logran mantenerlo ágil entre los micro front-ends, evitando recargas innecesarias y descargas adicionales, gestión de estado, etc.? Ahí, en realidad, una de las cosas en las que confiamos es el uso de módulos de ES y un CDN consistente. No es tan elegante y sin problemas como parece. Recomendamos un CDN específico. Siempre usamos el mismo CDN. Fijamos versiones para cosas que sabemos que tienen estado. Pero el CDN que usamos, en realidad tenemos una implementación interna para compartir nuestro código propietario con usuarios internos. Pero el propio CDN está altamente almacenado en caché. Por lo tanto, los módulos se cargan muy rápidamente. También confiamos en HTTP2 y estándares más nuevos. Por lo tanto, no importa tener muchas conexiones necesarias, necesitar buscar muchas dependencias. Pensaríamos que eso era algo antiguo. Pero con la tecnología moderna, realmente no lo es. Entonces, sí, intentamos confiar en la tecnología moderna. Hay un par de preguntas aquí que voy a agrupar, que es la gente preguntando, ¿por qué no esta otra cosa, verdad? Que siempre surge. ¿En qué se diferencia esto del Module Federation de Webpack o el enfoque de Nexus? Mm-hmm. Module Federation, la versión de usar micro frontends de esta manera significa que en realidad no construyes todo junto.

Por lo tanto, no necesitas saber qué módulos has cargado para construir tu aplicación host. Sé que hay algunas preguntas sobre por qué has elegido esto. Porque creo que para ser opinativo, tienes que tomar una decisión. Esas decisiones han surgido con el tiempo, y a menudo la gente cuestiona, ¿por qué hiciste esto? Y ahora lo tomamos caso por caso, y tenemos que evolucionar.

Y en la misma línea, es ¿Cómo haces cosas específicas, como la autenticación de usuario en múltiples módulos, o la comunicación entre un micro front-end en la aplicación desplegada, y el otro si existe? Así que en la versión que funciona, por favor ven a verme más tarde. En la sala de preguntas y respuestas de los ponentes, cerca del vestíbulo. De hecho, mostré la cuadrícula hablando con esa vista de tarjeta, y se comunican entre sí. La respuesta que tenemos internamente es parte de esa plataforma digital en la que proporcionamos servicios de plataforma. Cosas como la autenticación de autorización se realizan al iniciar la aplicación host. Hay un sistema arcano para la autorización, pero es manejado por la aplicación host. Entonces, cuando se carga una aplicación, puede definir qué credenciales debe tener el usuario. Y luego el host se encarga de asegurarse de que se hayan obtenido.

Eso es genial. Tenemos muchas más preguntas, pero desafortunadamente no mucho más tiempo. Así que agradezcamos a Steve. Y puedes encontrarlo más tarde en la sala de preguntas y respuestas de los ponentes. Gracias por unirte a nosotros. Muchas gracias. Puedes irte. Gracias.