¿Es Module Federation adecuado para ti?

Gracias a todos por unirse a nuestro masterclass hoy. Tenemos aproximadamente 2 horas y media para hablar sobre la federación de módulos, pero realmente no podemos hablar sobre la federación de módulos sin hablar sobre micro-frontends. Así que vamos a hacer una breve introducción sobre qué son los micro-frontends y por qué son útiles, por qué estamos aquí. Y luego trabajaremos en ejemplos.

Cuando terminemos con los ejemplos, si todavía están interesados en la federación de módulos, también voy a mostrarles algunas diapositivas sobre posibles arquitecturas, las arquitecturas a nivel de sistema que pueden elegir. Y también les mostraré algunas diapositivas que he aprendido que funcionan bien al presentar micro-frontends a jefes, empresas, clientes, y demás. Cosas que les gusta escuchar, porque generalmente no hablan el lenguaje de los ingenieros, y quiero compartir algo de eso. Así que lo tendrán. La presentación estará en el repositorio de GitHub, y se los compartiré en un momento.

Pero antes de hacerlo, nuevamente voy a tomar un segundo para presentarme. Mi nombre es, bueno, Gregor es la forma fácil de pronunciarlo, la forma oficial sería Gergoor, lo sé, es terrible, muchos erres rodantes. Pero he estado trabajando con la federación de módulos y Microfurence durante un tiempo, y no soy el inventor de nada de esto. Así que si conocen a personas como Zack Jackson, quien creo que es el cerebro detrás de Microfurence, y Toby Carver de Webpack, esos chicos son increíblemente inteligentes. Pasé mucho tiempo con esos dos a finales de 2020 cuando Madoff Federation estaba disponible, porque lo usamos ampliamente con algunas compañías grandes, no voy a mencionar nombres, pero algunas de las grandes en comunicaciones, en la industria automotriz, en farmacéuticas. Verán sus logotipos al final, pero no los mencionaré. Así que he estado trabajando con micro-frontends durante mucho tiempo y los he implementado en aproximadamente 200 países, y creo que muchos millones de usuarios ya han accedido a algunas de esas cosas, algunos de esos micro-frontends que ayudé a crear. Y hoy solo quiero compartir esa experiencia con ustedes. Quiero compartir, ya saben, hemos pasado por muchos descubrimientos increíbles y momentos difíciles, problemas difíciles de resolver. Porque estos son sistemas altamente escalables. Escalables en términos de infraestructura, escalables en términos de equipos escalables, multinacionales. Así que si trabajan con alguno de ellos, espero que esto les sea útil. Durante este masterclass, hablaremos, nuevamente, sobre qué son los microfrontends y por qué el negocio de ustedes o el negocio de sus clientes debería preocuparse. Crearemos un clúster de aplicaciones de federación de módulos muy, muy simple. Será muy simple porque este es un masterclass introductorio. Y habrá muchos ejemplos para mostrar, muchos problemas y soluciones para mostrar a través de ese pequeño clúster. Mostraremos cómo lidiar con algunos de los problemas más comunes, como trabajar con dependencias, cómo lidiar con los problemas que surgen al trabajar con dependencias, tipos de dependencias, y estrategias para lidiar con diferentes tipos de dependencias. Luego, una de las preguntas más comunes es cómo nos comunicamos entre módulos federados. Y creo que la comunicación es donde se hace o se deshace todo. Voy a mencionar brevemente o hablar brevemente sobre la modulación en aplicaciones híbridas. Así que no tiene que ser solo web. Puede ser híbrido. Puede ser completamente universal, ya sea web, PWA, escritorio o móvil. Hay algunas implicaciones muy interesantes allí. Nuevamente, hablaremos sobre la organización de equipos, la organización de trabajo con sus repositorios, compartición de código. Así que mezclaremos mucho de eso. Finalmente, reservaré tiempo para preguntas y respuestas. Una cosa que quiero que obtengan de esto es que quiero que suenen inteligentes cuando regresen a sus trabajos, a sus compañeros, a quienes hablen, a los meetups. Quiero que suenen inteligentes.

Hoy me sucedió algo interesante, esta mañana, estaba trabajando con uno de esos fabricantes de automóviles, un equipo al que estoy ayudando allí, me dijeron, así que tuvimos ciertos problemas con el renderizado del sitio de servicio de la federación modular federada. Pero esos son solo problemas que ocurren con sitios enormes, enormes, cuando tienes que ejecutar un servicio que renderiza decenas de miles de páginas al mismo tiempo. Y no sabía cómo resolver el problema. Así que dije, saben, lo buscaré en Google. Lo encontraré y lo agregaré. Así que creé una solicitud de extracción. Y dentro de la solicitud de extracción simplemente agregué algunas banderas que necesitaba agregar a este Chrome sin cabeza. Y dijeron, oh, no sé cómo llegamos a ser tan inteligentes. ¿Cómo encontraste todas esas banderas? Y dije, lo busqué en Google. Así que no fui inteligente. Simplemente lo busqué en Google. Así que este es nuestro momento de compartir, ya saben, no es buscar en Google, pero voy a compartir algunas cosas, espero que las lleven de vuelta a su trabajo. Además, voy a tratar de no usar palabras difíciles. Así que no se van a volver inteligentes de una manera en la que van a usar aplicaciones isomórficas, algo así como ese tipo de terminología, voy a tratar de ser simple. Así que si tienen experiencia, como sé que algunos de ustedes tienen con la iteración de modelos, por favor intenten escuchar. Si no tienen experiencia, si no son técnicos, espero que puedan, por eso espero que puedan comprender de qué estamos hablando.

Y como comenzamos, también quería establecer nuestro acuerdo de trabajo. Si tienes alguna pregunta, puedes usar la aplicación Zoom y Skype. Es una excelente manera de conocer a nuestros participantes. Zoom tiene esa función de levantar la mano, si tienes una de las últimas versiones de Zoom. Si no la tienes, de todas formas intentaré hacer pausas de vez en cuando para ver si hay preguntas. También puedes usar Discord y escribir tus preguntas, y en algún momento comenzaré. Es hora de que pensemos en nuestro entorno, porque voy a pasar unos minutos en el aspecto de presentación y mientras lo hago, siéntete libre de configurar tu entorno.

Entonces, vamos a trabajar con VS Code. Voy a trabajar en espacios de código, lo que me permite compartir el entorno completo contigo. Voy a usar Live Share y este es un buen momento para estar en Discord. Voy a pegar. Voy a enviar un mensaje con cómo puedes acceder a estas cosas. Entonces, si ves el mensaje en Discord, te envié las respuestas al repositorio de GitHub y aún no hay nada más que esta presentación, así que puedes llevarte esa presentación contigo a casa. Y tienes un enlace a VS Code Live Share. Si haces clic en él, podrás seguirlo tanto en tu VS Code como en la web. Sé que algunos... no todos usan VS Code, pero aún es bueno usar Live Share porque podrás ver mi código, verás mi sistema de archivos, mi terminal, podrás copiar y pegar cosas que yo ponga adentro. Muy bien. Te aceptaré a medida que te vea, pero seguiré adelante. Si alguno de ustedes tiene problemas con la configuración de su entorno por alguna razón, y si tienes preguntas al respecto, realmente te animo a publicar preguntas en Discord. Y como somos una comunidad, si alguien más tiene una respuesta a las preguntas de alguien, siéntete libre de compartirla. Es posible que no pueda hacer dos cosas a la vez, hablar y ayudar a alguien con configuraciones de entorno particulares, pero si fueras tan amable de ayudar a esas personas, sería fantástico. Muy bien.

Los micro-frontends son un ecosistema fantástico que ayuda a las empresas. Han existido durante al menos 20 años, que yo sepa. De hecho, conozco ejemplos que tienen 21 años, como IKEA. Han estado presentes durante mucho tiempo, ayudando a las organizaciones a descomponerse, como en esta imagen de la Fórmula 1. Cada uno hace su trabajo, ellos saben exactamente todo sobre esos neumáticos, y así es como son realmente eficientes al cambiar los neumáticos. Y eso es a lo que los micro-frontends nos dan acceso. Esas aplicaciones grandes y escalables son realmente una colección de características, una colección de pequeñas piezas que crean una grande. Es algo así como pensar localmente, actuar globalmente. Permite a los equipos centrarse en lo que mejor saben hacer. Hacer una cosa a la vez y hacerla muy bien, como en el ejemplo de la Fórmula 1. Los equipos pueden centrarse en una sola unidad de negocio y mantenerla. No tienen que mantener todo. Y es genial porque ni siquiera tienes que preocuparte por las otras piezas del rompecabezas porque alguien más se encarga de eso también. Ese es el tipo de entorno que estamos tratando de crear.

En un entorno de micro-frontends, básicamente estamos desacoplando. Estamos descomponiendo un monolito. A partir de un monolito, creamos múltiples pequeñas características descentralizadas. A partir de ahora, generalmente me referiré a ellas como aplicaciones de características, ¿de acuerdo? Porque las características, para mí, señalan algo muy independiente de una sola unidad de negocio. Y cuando digo aplicaciones, todos pensamos en algo muy cohesionado e independiente, ¿verdad? En esta ilustración, por ejemplo, puedes ver cómo un monolito se descompuso en características como la página de inicio, la autenticación, el carrito y el proceso de pago. Esas son unidades de negocio que se mantienen de forma independiente. Idealmente, también son mantenidas por equipos independientes. Y eso es lo que estamos creando con los micro-frontends y la federación de módulos. Estamos creando estas unidades de negocio descentralizadas. Como ejemplo, creo que muchos de ustedes ya lo saben, Spotify es un ejemplo de una aplicación de micro-frontends. Esta ilustración no muestra exactamente cómo lo hacen, pero es solo una ilustración. Puedes ver cómo un equipo trabaja solo en un reproductor de audio. Se centran en eso. Se centran en los códecs, en la interacción entre el reproductor y el sistema operativo. La interacción con el reproductor cuando estás en el automóvil. Cómo funciona el Bluetooth, seleccionando diferentes altavoces disponibles. Puedes decir que quieres escuchar la canción en tu sistema de cine en casa. Hay un equipo que trabaja solo en eso. Otro equipo trabaja en las recomendaciones. Aún así, hay una sola aplicación cuando la vemos de manera holística, pero está compuesta por diferentes componentes. Hoy veremos cómo podemos conectar esos componentes entre sí.

Lo genial de los micro-frontends es que son increíbles para el trabajo en equipo. Los equipos saben exactamente con qué trabajan, conocen exactamente su dominio empresarial. Cuando se utilizan en un entorno ágil, esos equipos pueden trabajar muy bien y comunicarse. Sabes a quién acudir cuando hay un problema. Por lo tanto, en ese sentido, los micro-frontends son más un marco organizativo que una pila tecnológica. Es muy fácil aprender los micro-frontends como una pila tecnológica. Es un poco más complejo ser un arquitecto de esa solución, pero es mucho más complejo crear una organización que funcione de esa manera. Lo digo porque algunos de ustedes pueden estar trabajando en organizaciones que quizás no estén al día con cómo viven y trabajan algunas de esas organizaciones modernas y ágiles, y está bien. Eso está bien. Algunas organizaciones tienen muchos acuerdos contractuales y muchos procesos y demás. Y he visto eso. He visto eso en organizaciones que necesitaban... Fue un poco más difícil para ellos adoptar este cambio que para los tipos de organizaciones más modernas. Pero fue un cambio. Creó una empresa mejor. Entonces, si estás en una empresa así, nuevamente, está totalmente bien. Puede funcionar. Ahora, para los micro-frontends, tenemos múltiples patrones arquitectónicos. No mencionaré todos, pero históricamente, la gente ha utilizado además de la federación de módulos, algunos han utilizado frames o iframes. Es una tecnología muy antigua. Entonces, ¿por qué no? Puedes conectar frames y mostrar diferentes partes de un sistema. Como un menú puede ser un frame. Suena mucho a los años 90, pero como dije, no son nuevos. Las inclusiones del lado del servidor es algo que ha existido durante mucho tiempo. Creo que así es como comenzó IKEA. Hay una alternativa a eso que son las inclusiones del lado del borde o en la nube, donde combinas todo en la nube. Nuevamente, es posible hacer varias adaptaciones con repositorios de Git como submódulos, incluso monorepos. Y eso está bien, eso es bueno, no hay problema, pero vienen con... No es tan bonito y fácil como con la federación de módulos. Tiene algunas desventajas. Y finalmente, los módulos de NPM es probablemente algo que la gente más a menudo dice: `Bueno, los módulos de NPM están bien, puedo trabajar con los módulos de NPM e importar bibliotecas que alojo en mi registro personal, así es como voy a hacer mis front-ends`. Y eso es totalmente válido. Pero lo bueno de la federación de módulos, creo que aporta el beneficio, son dos cosas. Una es que los módulos están conectados en su totalidad, ¿verdad? Y la unidad completa en la aplicación, en tiempo de ejecución. Y eso es importante, cuando no tienes que reconstruir la aplicación, simplemente cambias, reconstruyes la característica a la que estás conectado, como el menú de navegación. Tienes que reconstruir eso, pero a medida que hay una nueva versión disponible, se introduce automáticamente en la aplicación. Y eso te permite hacer cosas locas, como por ejemplo, permitir que un cierto subconjunto de usuarios prueben versiones beta, o si te encuentras con un error en una nueva compilación, puedes auto-repararlo y reemplazar esa navegación federada con la última versión conocida y buena. Y eso se puede hacer en tu propia infraestructura con la federación de módulos, porque se construye en tiempo de ejecución. Lo otro que la federación de módulos hace realmente bien es lidiar con las dependencias, y vamos a hablar de eso. Nuevamente, hay otros, también hay otros, voy a decir, marcos, y realmente no puedo hablar de muchos de ellos porque he investigado mucho. Pero lo que realmente me gusta de la federación de módulos es que está basada en estándares. Tiene un tiempo de ejecución mínimo y se basa en todo lo que se convierte en un estándar para la comunidad de JavaScript. No tiene opiniones. No tienes que preocuparte por el marco. Puedes no usar ningún marco. Puedes usar JavaScript puro. Puedes usar React. Puedes usar Vue o Angular o cualquier otra cosa. Simplemente funciona.

Hay cierta positividad en torno a los héroes. Así que creemos una nueva aplicación, creemos una aplicación llamada Hero. Está bien, estoy copiando AppCore, y tendrías que crear uno nuevo, pero está bien si copias. Lo voy a llamar Hero. Debido a que copiamos, debemos asegurarnos de ir al archivo package.json y nombrarlo Hero, solo eso, ¿verdad? El nombre está aquí, y eso es importante para Lerna porque Lerna identifica las aplicaciones por nombre, no por carpeta. La configuración de Webpack es la misma. Todo es lo mismo, vamos a cambiar. Bueno, vamos a cambiar esta iteración del módulo, el ejemplo de la aplicación raíz, esto no es un ejemplo de aplicación raíz, esto es Hero. Esto es Hero, está bien. Ese es el título para que sea más fácil identificar las pestañas. Debido a que copié y tenemos renderHero. Rendericemos hola, voy a cambiarlo a render. Tenemos createElement h1, voy a crear h2. Y tenemos hola mundo, me siento heroico, genial, exclamación. Y un hijo de pluma, es más o menos lo mismo. Podemos ejecutarlo, ¿verdad? Ya tenemos este servidor de desarrollo, así que necesitamos crear uno nuevo. Esta es una nueva terminal. Hay un pequeño truco que me gusta hacer para no tener que sumergirme, cuando uso Lerna, para no tener que sumergirme en cada paquete, ¿verdad? Si voy a package.json, voy a crear accesos directos para esto. Y tengo estos accesos directos disponibles para que pueda copiar y pegar, tú también puedes copiar y pegar. Así que dentro del package.json raíz, creé dos nuevos scripts. Uno es para, el otro es hero. El primero, básicamente hace esto, estás en el espacio de trabajo, así que encuentra un espacio de trabajo que se llama app core y ejecútalo. Entonces significa ejecutar el comando serve. Así que eso es lo que estamos haciendo. Y aquí es lo mismo. Así que guardé esto, creo. Y si hago yarn, así que estoy en la raíz, ¿verdad? Si hago yarn hero, no hizo nada. Oh, porque estoy en app core. Lo siento, no en la raíz, ahora estoy en la raíz. Yarn hero, ahí lo tienes. Este es el puerto 8081. Vamos a tratar de mantener los puertos 8080 y 8081 para que sepamos dónde están las cosas. Ahora no podrás verlo hasta que marque esto como público, ¿de acuerdo? Ahora puedes usar la misma URL, solo cambia 8080 por 8081 como aquí. Y vemos, me siento heroico. De acuerdo, ahora tenemos dos aplicaciones. Y ahora viene, espero, la nueva parte. Ahora viene la parte en la que usamos la federación de módulos para esto, veamos. Estamos aquí. Para esto, voy a ir al archivo webpack-config de cada uno de estos, ¿verdad? Voy a ir a Hero primero. Esta es la configuración de webpack. Para activar la federación de módulos, ahora sé que esto está disponible en mil readme y documentación de la federación de módulos. Básicamente, esto es todo. Solo requieres webpack.container porque el complemento de federación de módulos es parte del contenedor de webpack. Y cuando lo importamos, simplemente agregamos un nuevo complemento. Nuevo, NRE nuevo complemento de federación de módulos. De acuerdo, así que tenemos la IA que intenta sugerir que pongamos un nombre. Sí, así que le vamos a dar un nombre. Voy a obtener un nombre y no lo voy a llamar app core, lo voy a llamar core. Es una buena práctica nombrar tu módulo federado o voy a decir tu aplicación de características. Es un buen hábito nombrarlo porque es un identificador. Es importante que este nombre sea algo que sea legible para JavaScript, ¿de acuerdo? Porque la forma en que se inyecta en la página, a menos que cambiemos las cosas, es básicamente la etiqueta de script que se está inyectando tendrá una variable llamada var core igual a una función de llamada automática. Así que básicamente, si quieres hacer algo que no sea JavaScript como esto, esto se romperá. Pero si quisieras hackearlo y hacer esto, esto no funcionará a menos que definas core primero, pero en realidad puedes escribir JavaScript en este nombre, lo cual podría ser, es un truco pero podría ser interesante en ciertos escenarios. Bien, no necesitamos trabajar con library. Solo necesitamos darle un nombre. Ahora hemos instanciado marzl-federation. Cuando le damos un nombre, eso se llama library. Ahora creamos una nueva biblioteca llamada core. La biblioteca es como, es como un paquete npm, ¿verdad? Es un nombre para algo que va a contener algunos submódulos. Así que core, y necesito decirle a marzl-federation qué es lo que estoy haciendo accesible para otras aplicaciones. Necesito declarar qué es lo que otras aplicaciones pueden usar de esta. Y eso se llama expone. Voy a exponer algo. Entonces, voy a, bueno, voy a darle un nombre. Voy a darle un nombre más adelante, pero voy a señalarlo a source index.js. De acuerdo, eso es fácil de entender, ¿verdad? El archivo index.js se va a exponer, pero ¿bajo qué nombre? Porque estábamos trabajando con vanilla JavaScript, lo voy a llamar vanilla, aunque necesito agregar un prefijo de barra diagonal. De acuerdo, porque verás por qué, porque podemos exponer varias partes, varios archivos, varios módulos, y accedemos a ellos cuando importamos, ¿verdad? Los vamos a importar como import core-vanilla, ¿verdad? ¿Verdad? De acuerdo, así es como va a funcionar. Por eso es barra diagonal vanilla. De acuerdo. Así que hemos indicado qué es lo que estamos exponiendo, y ahora vamos a repetir básicamente lo mismo. Permíteme copiar esto, pegarlo como configuración de webpack de la aplicación core. Así que estoy copiando la importación, y estoy copiando todo este bloque. Nuevo complemento de iteración de módulo. Ah, no, lo voy a escribir. Nuevo complemento de iteración de módulo. Cerrándolo, así que nombre. Iba a preguntar, ¿cuál es el nombre, pero la IA no lo hace divertido. Así que no vamos a exponer nada. Podemos, no necesitamos. Podemos exponer todo y cualquier cosa, pero en este punto no necesitamos exponer. Ahora estamos en este lugar, podemos definir qué es lo que estamos consumiendo de forma remota. De acuerdo, así que vamos a decir que hay un remoto, que hay un módulo remoto que queremos usar. De acuerdo, el módulo remoto se llamará. Voy a darle un nombre, algo que conozco. Así que podemos confiar en esta autocompletación de hero hero, podemos hacerlo totalmente. Hay un remoto que se llama hero. Lo voy a llamar hero localmente, y se llama hero en el remoto. Pero hay este pequeño truco genial. Entonces, la pregunta es ¿por qué ambos microfrontends usan el nombre core? Déjame ver, ¿lo están haciendo? Así que la configuración de webpack está en la app core, el nombre es core.

El archivo webpack-config a continuación, oh, tienes razón, gracias. Esto no es core, esto es hero. Gracias, Lars. Entonces este es hero. El de arriba es core, buen atrapada. Bien, ahora, cómo defino remoto. Técnicamente hay, bueno, hay varias formas de cómo defino dónde está remoto. Hay una cosa que es realmente genial que me gusta usar cuando comenzamos. En producción, creo que no tiene mucho valor pero te mostraré más adelante por qué. Aunque cuando lo nombro hero en, okay, ¿y ahora en qué? Voy a copiar esta URL. Hero en y luego toda esta dirección, puerto 8081 porque hero está en el puerto 8081 slash 8081. Ahora hay algo que se llama, ya sabes, como index.html es muy importante index.html muestra enlaces a todos los archivos JavaScript, estilos, etc. Es como un archivo meta. También hay un archivo meta para estos módulos federados. Por defecto, el nombre será el mismo que el nombre del módulo, hero.js. Podemos cambiar esto en una configuración. Personalmente prefiero, prefiero llamarlo remote.js para tener un nombre consistente. Pero por defecto, a menos que cambiemos algo, se llamará hero porque este nombre es hero. De acuerdo. Hero.js. Cuando lo pongo así, entonces estoy dejando que Webpack lo resuelva. De acuerdo. Así que ha llegado el momento de recargar porque tenemos un nuevo Webpack y arreglar, y este está mal. Está completamente bien. ¿Qué hay de malo en esto? Remotos en plural. De acuerdo. Y reiniciemos este. Es importante. Cuando trabajamos con un servidor de desarrollo de Webpack, es importante lanzarlos en un cierto orden porque no he definido la configuración del servidor de desarrollo, los puertos se asignan automáticamente. Así que tengo que reiniciar el lado izquierdo primero para que siempre sea el puerto 88, y una vez que haya ocupado el puerto 88, luego reinicio el segundo para que el segundo sea el 881. De lo contrario, tendría que cambiar esto Azure de vez en cuando. De acuerdo, reiniciémoslo y veamos si funciona. Esto es Hero, Hero tal vez funcione. No muestra mucho. Bien, no hice las cosas, no hice que los puertos fueran públicos. De acuerdo, esto es por qué está autenticado. Está bien, esto funciona pero aún no está sucediendo nada. ¿Verdad? Lo que no hice, no importé. Entonces lo siguiente que voy a hacer, voy a ir a la aplicación core, ¿verdad? Defino mi configuración de Webpack, Webpack sabe que hay una biblioteca Hero que no está en los módulos de Node, existe en esta ubicación remota. Entonces cuando lo uso, cuando lo consumo, va a saber de dónde tomarlo. De acuerdo, tenemos render hello. Ahora vamos a tomarlo de Hero. Y en Hero se llama Render. Ahora, hay una cosa que no hice. ¿Cómo voy a importar la función de renderizado si nunca la exporté, ¿verdad? Así que voy a hacer export default render. De acuerdo, quiero asegurarme de exportarlo como una exportación predeterminada. Así que no es nombrado, debería ser el predeterminado. Volviendo aquí. Y creo que ya te mostré esto. Importo render, voy a llamarlo render hero porque es la exportación predeterminada. Desde, okay, hero slash, slash, ¿alguien puede ofrecer slash qué? Lo voy a poner aquí. De acuerdo, hero slash vanilla. Es una V mayúscula, no tiene que serlo. Probablemente no pondría una mayúscula pero hacemos esto, render a hero. Así que lo voy a poner justo debajo de este, render hello luego render hero. De acuerdo, ahora veamos si esto va a funcionar. Voy a recargar y no, no funcionó. Hay algo que me impide cargar. Y este detalle es importante. Si ya has trabajado con la federación de módulos de Webpack, probablemente sepas qué es. Si nunca has trabajado con esto, es importante mencionarlo. Cuando comienzas con tu módulo federado, el primer módulo debe importarse de forma dinámica. Así es como lo hacemos y luego te explicaré por qué. Voy a copiar index.js y pegar. El original se va a llamar vanilla, lo llamo vanilla. Va a ser vanilla. Y luego el primero, index.js, voy a borrar esto. Cierro esto para no confundir. El punto de partida, el punto de entrada debe importarlo, de forma dinámica. Esto no es una importación estática, esto es una importación dinámica, que funciona de forma asíncrona. Y la razón por la que es importante es porque tenemos que darle tiempo a Webpack para que resuelva el runtime, para que resuelva dónde están las dependencias, para que resuelva dónde están los módulos remotos. Así que esto es ese primer paso. Si te preocupa una penalización de rendimiento al iniciar tu aplicación de forma asíncrona, medí un enorme, ese sitio que tiene decenas de miles de páginas y tiene varias docenas de características generadas desde un CMS en la página. Y tarda unos 150 milisegundos en iniciar el renderizado. Así que es muy rápido, ¿verdad? Son realmente 150 milisegundos para un sitio enorme. Es muy rápido. Y no es en mi computadora, es en una computadora que mide el rendimiento que es una computadora de baja especificación. Así que esto no va a perjudicar negativamente a tu aplicación. De hecho, es muy importante. Bien, esta es la aplicación core. Creo que ahora puedo recargar, okay, esto funciona. Así que comparemos esto, dame un segundo. Antes de hacer eso, sé que no es justo que estos puertos sean privados, deberían ser públicos. De acuerdo, cada vez que reinicio el servidor de desarrollo, tengo que hacer esto de nuevo. Así que ahora son públicos y cuando reinicio, obtengo lo mismo, ¿verdad? Cuando reinicio Hero, obtengo lo mismo. ¿Qué pasó aquí? Entonces, lo primero que sucede, ves, I feel Heroic aparece dos veces. Parece un error. Pero recuerda esa importación dinámica. La Federación de Módulos a Runtime dijo, okay, tengo un remoto llamado Hero.

Voy a cargarlo porque el resto de la aplicación depende de él. Así que es una etiqueta de script y probablemente valga la pena mostrar esto no como fuente, sino como elementos probablemente. Así que probablemente no aquí. De todos modos, es una etiqueta de script como ves aquí, Fuente vanilla, que viene del puerto 8080 y Fuente index viene del puerto 8081. Si lo previsualizo, vemos un poco de el runtime y luego vemos nuestro texto. Dice función render. Declaramos la función, pero también ejecutamos la función. Cuando ejecutamos la función, dibujó esto primero, Me siento heroico. Por eso lo vemos dos veces, porque ejecutamos la función la primera vez, y luego la ejecutamos la segunda vez. Si vuelvo al código, tenemos render hero, pero también ejecutamos la misma función desde dentro del componente hero. Sin embargo, debería hacer el mismo ejercicio aquí. El mismo cambio de nombre como indexación es vanilla JavaScript. Esto va a romper la aplicación por un segundo, y necesito usar esta importación para que funcione correctamente. Pero eso no es todo, en Webpack, necesito cambiar vanilla, ya no va a apuntar a este index, porque no es donde está mi lógica de negocio. Mi lógica de negocio está en vanilla JavaScript aquí mismo. Creo que necesito mover esto aquí arriba. En Webpack, voy a reemplazar esto con esto expose, voy a explicar con vanilla. Ahora tenemos las cosas en orden, ahora los runtimes se están fusionando para entender las dependencias entre sí. Esto debería funcionar con suerte. Bueno, tendría que reiniciar este servidor de desarrollo. Absolutamente. Voy a hacer una pausa por un segundo. Sé que voy rápido, principalmente por razones de tiempo. Pero este es un buen momento para decirme si tienes alguna pregunta.

No. De acuerdo. Voy a ir. Pregunta muy rápida. Sí. En este escenario, ¿se supone que un núcleo debe ser la aplicación envolvente o ambas aplicaciones son, digamos, hermanas? No me queda claro si una aplicación es el contenedor y la otra es el contenido o si son aplicaciones hermanas. Bueno, puedes hacer ambas cosas, ¿verdad? Obviamente, creamos una dependencia circular si el núcleo importa a hero y hero importa al núcleo. Pero lo hermoso- Es una excelente pregunta porque lo hermoso es que usamos el núcleo como un contenedor, pero el núcleo también puede ser una característica. Por ejemplo, te voy a dar un ejemplo muy simple que espero que nunca uses en la vida real. Por ejemplo, menú. Lo uso porque es algo simple. Puedes tener una aplicación de característica llamada menú y luego cada elemento de menú puede ser su propia aplicación de característica. Por lo tanto, pueden anidarse. Entonces, un menú anida un elemento de menú, pero luego tienes una barra lateral que anida el menú y luego tienes tu núcleo de aplicación que anida la barra lateral. Correcto. Puedes tener esa profundidad. Ahora, la razón por la que dije, espero que nunca uses eso es algo de lo que quiero hablar después de hacer los ejercicios, pero aún así lo mencionaré ahora. Espero que no lo hagas porque hay una línea clara. No, hay una línea muy difusa que debemos aclarar. Y eso es lo que hace que un Módulo Federado, lo que hace la característica, ¿verdad? ¿Es un componente? ¿Va a ser un elemento de menú? ¿O va a ser, qué tan grande tiene que ser? Ese es un problema muy importante para resolver porque, bueno, en mi opinión, debe ser una unidad de negocio. Un elemento de menú no es valioso como una unidad de negocio. Un menú podría ser valioso, pero no queremos ser demasiado granulares. Cuando te vuelves demasiado granular y tienes este alto nivel de granularidad y luego tienes que mantener la península, se vuelve muy, muy difícil de mantener. No te va a afectar si trabajas en esto ahora y si ya lo has hecho. Probablemente no te afectará durante el primer año, pero a medida que la aplicación crece, se volverá exponencialmente más difícil si tienes una estructura demasiado granular, pero si te enfocas en el valor empresarial, si tienes un equipo que trabaja en la authentication, una pantalla de inicio de sesión o preferencias de usuario, no es demasiado pequeño, no es demasiado grande, tiene valor empresarial. Hay un equipo que tiene experiencia en authentication. Este equipo está formado por profesionales de la security. que saben cómo escribir hermosas interfaces de usuario y saben cómo escribir, no sé, microservices en AWS, y son expertos en authentication. Ese es un gran ejemplo de una característica que puede ser federada.

De acuerdo. Falló solo porque GitHub aún no lo propagó, pero ahora funciona bien. Tenemos un ejemplo funcional, gente. De acuerdo. Perdón si voy demasiado rápido. Me encantaría repasar muchas cosas contigo. Lo bueno es que esta masterclass está grabada. Así que una vez que se publique, siempre puedes retroceder y ver lo que hemos hecho. Ahora, vamos a hacer esto. Intentemos, ya sabes, hagamos esto. Intentemos, probablemente hay cosas que no debería verificar, creo que funcionó a través de mi Gitignore, pero está bien. Ese es el ejemplo uno. Creo que esto será suficiente. Ejemplo uno, lo tenemos. Voy a guardarlo, subirlo. Muy bien. Clase. Si vas a GitHub, ahora tienes todo este código verificado. Así que puedes revisarlo y trabajar con él. De acuerdo. Nuestro próximo paso será agregar dependencias. Y la primera dependencia que quiero agregar, puedo detener fácilmente este servidor porque no lo necesitaremos. Lo siento. Entonces, lo primero que quiero agregar es que voy a reemplazar este JavaScript puro con una biblioteca de renderizado de vistas. Voy a usar React, ¿de acuerdo? Si has usado React, este será un ejercicio interesante. Si no eres usuario de React, será muy, muy simple. Espero que puedas seguir y llevar contigo las cosas que realmente quieres saber. Entonces, para agregar React, déjame ver, ¿qué necesitamos? Necesitamos, solo voy a copiar y pegar algunas de estas dependencias. Para, vamos a borrar esto. De acuerdo. Para el espacio de trabajo, WD al final, el espacio de trabajo y el desarrollo. Vamos a agregar Babel preset react. Eso significa que en este cargador de Babel, el cargador de Babel, voy a agregar configuración y eso serán opciones. Puedes copiar y pegar para ahorrar tiempo. Entonces, en el cargador de Babel, agrego opciones, preset Babel preset React que acabo de agregar. De acuerdo. Con opciones, runtime automático. Entonces, lo que esto significa es que nos permite ser perezosos cuando usamos runtime automático. Nos permite no tener que escribir import React from React. Esto creará automáticamente ese runtime de GSX. De acuerdo. También necesitamos esto. Esto es para el WebPack de heroes. También lo agregaremos al WebPack de course. Ahí vamos. Tenemos la misma configuración en ambas aplicaciones. También voy a agregar React y React DOM. Ahora, curiosamente, he usado Yarn para todo hasta ahora. Pero ahora voy a introducir dependencias. Esas dependencias son de desarrollo, ¿verdad? No nos importa. No nos importa construir con esas dependencias, pero nos importa la dependencia real. Las dependencias no son de desarrollo, son dependencias reales. Así que debemos agregarlas en los respectivos package.json, ¿verdad? Ahora mismo, no tenemos ninguna dependencia, así que debemos agregarlas aquí. Para hacer eso, no voy a usar Yarn y agregar. Voy a usar Lerna. Lerna me ayudará a agregar las dependencias correctas en el paquete correcto. Así que voy a usar Lerna add. Creo que voy a usar npx lernad. Entonces, Lernad react a packages star. Así que a todos los paquetes, de acuerdo. npx lernad react a todos los paquetes. Bien, casi bien. De acuerdo. Y React DOM. Muy bien. ¿Qué obtenemos de aquí? Voy a esperar a que termine. Enlazando, genial. Aquí tenemos el archivo package JSON. Tenemos dependencias. React y React DOM. Ambas son las últimas dependencias. De acuerdo. Cerrémoslo. Ambas son las últimas dependencias. Y están en ambos paquetes. Ambos son la misma versión también. De acuerdo. Entonces, ahora vamos a agregar, déjame ver. En la aplicación principal, agreguemos la carpeta de componentes, ¿verdad?, porque aquí es donde vamos a poner los componentes de React. Y voy a crear un nuevo archivo, lo voy a llamar app.js. Genial. Tenemos app.js. Y es simple. Lo tengo listo para que pueda simplemente ponerlo, ¿verdad? Creé una aplicación. Nuevamente, no tuve que hacer import React from React. Hola mundo, esta es la aplicación de React. Perfecto. Y lo exportamos. Ahora vamos a, así es como comienza la aplicación.

Normalmente en las pestañas de React, tenemos index.js y tenemos app.js, ¿verdad? Pero también necesitamos bootstrapear React. Necesitamos crear la aplicación de React asociada al nodo raíz. Y para eso, voy a crear un nuevo archivo, ¿de acuerdo? Vanilla está reservado para nuestro JavaScript básico. Lo voy a mantener. Ya no voy a tocarlo. Vamos a olvidarnos de vanilla. Pero tenemos este index.js que importa vanilla, ¿verdad? Así que agreguemos otro módulo. Lo voy a llamar bootstrap. Bien, y aquí es donde voy a bootstrapear React. Verás por qué esto es importante. También, interesante, ¿verdad? Solo copiando algunas de esas cosas de React. Bien. Así que importamos React esta vez y creamos la raíz. Probablemente ni siquiera tuve que importar React en este ejemplo, pero está bien. Así que importamos React para el componente app desde los componentes de la app, y eso está bien. Y en index.js voy a reemplazar esto, ¿verdad? bootstrap. Ahora, nota una cosa. Estoy, bueno, esto es el core, pero aún puedo exponer Vanilla aunque no se haga referencia en la app. Puedo crear nuevos módulos y explorarlos aunque no se usen en la app. Y eso es muy poderoso. Bueno, verás eso un poco más cuando trabajemos con Hiro. Así que reemplazo esto por bootstrap, y veamos si hay algo más que necesite hacer. Creo que tenemos todo casi igual. Bien. Ya hice eso en app.js. Ahora en Hiro, creo que puedo hacer lo mismo. Tenemos bootstrap. Voy a copiarlo. Bien, copiado y pegado, ahora está copiado. En index, voy a usar bootstrap. Bien. El mismo proceso. Mismo procedimiento. Probablemente necesitaré una nueva carpeta llamada componentes. Bien. Y voy a crear un nuevo componente. Lo voy a llamar componente Hiro. Un nuevo archivo. Está tardando. Bien, Hiro.js. Genial. También voy a usar app.js. Voy a copiarlo aquí. App.js. Bien. Y dentro de app.js, bueno, voy a cambiar esto un poco. Esto va a ser main. Solo estoy cambiando un poco la estructura porque puedo. Y dentro vamos a poner Hiro. Bien. ¿De dónde viene Hiro? Bueno, importamos. Lo vamos a importar. Import Hiro. Hiro de Hiro. Ahí vamos. Bien. Creo que todo desde aquí debería funcionar como esperamos. Vamos a tener dos aplicaciones. Probémoslo. No veo mucho de esto porque veo la transcripción. Puedo moverlo, genial. Yarn serve, y voy a reiniciar. Esto fue Yarn Hiro. Bien, fantástico. Tenemos dos puertos, lo mismo. Somos públicos, desearía tener un pequeño robot que pudiera hacer esto por mí. Si alguien más conoce un atajo, para que siempre sean automáticamente públicos, eso sería fantástico. Voy a recargar ambos. Esperando, esperando. A veces necesita despertar un poco. Bien, déjame verificar. Esto debería estar bien. Bien, es solo que el tráfico no está pasando. A veces los espacios de código pueden hacer eso, así que estás intentando reconectar. Bien, está bien, no voy a esperar mucho tiempo. Pero como puedes ver cuando cargamos, sí, están disponibles, se están reenviando. Oh, respondamos la pregunta. Veo algunas. Gracias, intento mantener la calma si puedo. También hace calor aquí. Felicidades por avanzar al nivel uno. ¿En un entorno de producción, el core y Vanilla se ejecutarían en servidores separados? Buena pregunta. Voy a hablar de eso en un momento. Porque puedes construir todo con estáticos, te recomendaría usar almacenamiento en la nube como S3. No es porque sea un fanático de AWS, puedes usar cualquier otro proveedor de la nube, pero aquí está la razón por la que es genial, porque es estático. S3 es un gran almacenamiento o algo como S3 es un gran lugar para archivos estáticos.

Puedes servirlo a través de CDN. Si generas archivos estáticos, recomendaría implementarlos, lo haces para CI, obviamente, cada implementación obtendría una nueva versión. Al igual que mantienes las bibliotecas de manera semántica, como la versión 1.2.3, recomiendo encarecidamente mantener una versión semántica similar para las características. Esto también te permitirá comprender las diferencias de versión menores y mayores. Pero si mantienes esas implementaciones, serán muy comunes, muy pequeñas, solo unos pocos megabytes de contenido, pero podrás tener que construir toda esta historia de versiones antiguas. Luego también podrás extraer muchas estadísticas útiles. Si tu versión de las cosas y si mantienes las cosas separadas, por ejemplo, un bucket por característica, obtendrás estadísticas increíbles. Sabrás qué características son populares, qué aplicaciones de características son populares, y así sucesivamente. Ahora, en una organización más pequeña y un producto pequeño, eso es más fácil de rastrear, pero en una enterprise grande, que sirve a decenas de millones de personas en todo el mundo, no lo saben porque los autores de contenido implementan estas características a través de un CMS. A algunos autores de contenido les gusta usar una versión u otra, o algunos países usan la versión 1 y otros países la versión 2. ¿Quién sabe qué más está sucediendo allí? Pero tu organización realmente puede rastrear la popularidad, el costo de la Cloud. Hay una serie de cosas en términos de información y recopilación de datos que puedes obtener, si lo haces de esa manera. Sin mencionar que se vuelve mucho más fácil hacer cosas como mencioné anteriormente, como la auto-reparación. Cuando te encuentres con un problema en una característica, hay un error y luego puedes retroceder fácilmente a una versión que ya está implementada, una versión anterior. Hay una serie de beneficios que provienen de eso.

En relación a lo anterior, ¿puedo inspeccionar, digamos, Spotify y abrir un reproductor? Probablemente no. Creo, siendo honesto, que lo sabía. Olvidé cómo Spotify hace su micro-ferencing. No lo sé. Si alguien en esta llamada es de Spotify, si quieres compartir, siéntete libre de hacerlo. No sé qué tipo de tecnología utilizan, o creo que usan multi-figuration. Entonces, probablemente no podrías hacer eso. Lo importante de esto es que espero que estés viendo que no se trata tanto de la tecnología. Vas a aprender estas formas de trabajar con agilidad y multi-figuration rápidamente. Lo importante es cómo organizas los equipos y cómo organizas el código en términos de soluciones. ¿Verdad? Y para ser claro, voy a tratar de ayudarte de inmediato. Si estás buscando implementar Module Federation en un proyecto pequeño, siempre sugiero que no lo hagas. No lo hagas por el factor de novedad porque va a tener un costo usar microfront. No es porque Module Federation sea algo malo, sino que está pensado para escalabilidad. Es lo mismo que implementar en AWS. Si usas muchos servicios, se vuelve difícil de mantener. Si usas una PWA, es más fácil de mantener. Pero una PWA para un sitio enorme, una PWA para, digamos Amazon, o un proyecto de module federation real, Office 365, ¿verdad? Ellos tienen este problema. Puede que sepas que han estado trabajando durante años en el problema de construir este enorme mono-lito. Tan pronto como comenzaron a desacoplar utilizando module federation, separando partes de la aplicación en características más pequeñas, se volvió mucho más fácil para ellos mantenerlo, pero más fácil porque es un producto enorme. Si estás trabajando en algo muy pequeño, es genial experimentar, pero probablemente, siendo honesto, no lo haría, simplemente porque, como dije, está pensado para algo más complejo.

La siguiente pregunta es, ¿cómo se gestionan los cambios rompedores y la federación de módulos? Cuando algunos módulos necesitan actualizarse juntos, Bien, déjame ver. Entonces hay cambios rompedores entre las dependencias y cambios rompedores entre las aplicaciones de características. Creo que la pregunta no se trata de las dependencias, sino que se trata del código empresarial en realidad. Cuando tienes cambios rompedores dentro de tus características y quieres identificar esos cambios rompedores y qué versiones puedes emparejar mejor, ¿verdad? Cuando usas tipos de características. Si esa es la pregunta, esa es... Lo que no mencioné es que, nuevamente, técnicamente, MyFederation también es crudo. Es agnóstico, es agnóstico de frameworks. Es agnóstico de lo que haces. Y realmente puede beneficiarse de infraestructura adicional. Algunos tipos de infraestructura adicional que puedes agregar a MyFederation pueden ser mantener tus propios metadatos de versiones, donde puedes mantener cambios y dependencias. Eso es bueno tener. He implementado para una organización este archivo de registro dinámico. Eso rastrea todas esas compatibilidades. Lo bueno de eso es, cuando llegamos a las dependencias, lo que sucede es que, puedes saber de antemano qué aplicaciones de características funcionan juntas. Es como ver en el futuro, sabes qué bibliotecas se van a utilizar para que puedas elegir las mejores versiones de antemano. Pero eso es a un nivel avanzado, ¿de acuerdo? No quiero confundirte con eso. Si estamos hablando de la forma más fácil de lidiar con cambios rompedores es seguir la versión semántica. Porque la versión semántica es muy clara acerca de los cambios rompedores. Las versiones principales tienen cambios rompedores. Las versiones menores tienen compatibilidad hacia atrás para cambios rompedores. Y en los parches, o nuevamente, los parches, no deben introducir cambios rompedores. Um, hay cambios rompedores en otro nivel, que se llama datos. Cuando las aplicaciones de características usan datos, consumen una cierta estructura de datos. Y luego sucede que tienes una versión más nueva de la característica, pero una versión más antigua de datos. Ese es otro problema que se presenta. Otra cosa que se puede hacer es mantener eso internamente. De acuerdo. Volvamos a esto. Gracias chicos por las preguntas. Medusa es genial. Y definitivamente deberías probarlo. Te pone en marcha. Bien. Así que tenemos un tiempo de espera de la puerta de enlace. Tiempo agotado. Eso está totalmente bien. Ni siquiera sé por qué, por qué esto se está agotando. Y espero que un simple reinicio lo solucione, lo cual es algo que voy a hacer ahora. Pero si no ayuda, está bien. Vamos a seguir adelante, para que podamos trabajar en esto. Me alegra que ustedes también estén copiando esto localmente y ejecutándolo localmente. Vamos a verificar si algo está sucediendo aquí. Compilación exitosa, exitosa ahora. De acuerdo. Conectando hacia adelante. Vemos esta pantalla adicional porque los puertos no son públicos nuevamente. No está conectado al puerto. Está bien, voy a seguir adelante porque quiero avanzar un poco, hacer que las cosas se muevan. Entonces, lo que creamos son dos aplicaciones, dos aplicaciones React. Si estás familiarizado con React, son muy simples. Una es una aplicación que muestra Hola, Mundo. Esta es una aplicación React. La otra es una aplicación que anida, de acuerdo. Y ese componente héroe, tiene un estilo básico que acabo de poner en una etiqueta de estilo. Podría haberlo puesto en cualquier otra etiqueta HTML también. Eso está totalmente bien. Voy a recargar esto una vez más porque quería funcionar. De acuerdo. Bien, no me está haciendo justicia. Es lo que es. Tal vez en un rato se arregle. De acuerdo, vamos a descansar un poco. Bien. Entonces, ¿qué tenemos aquí? Tenemos esas dos aplicaciones y lo que quería hacer, lo primero es también exportarlo. Ahora exportamos Vanilla Hero. También voy a exportar la biblioteca React. De acuerdo, Vanilla. Y luego vamos a tener, solo lo voy a llamar héroe, ¿de acuerdo? No, lo voy a llamar de otra manera. Sí, componente héroe. Componente, de acuerdo, y esto va a ser source slash components slash hero, ¿de acuerdo? Uso Hero, y aquí está la razón. Este es un gran lugar para el mapeo mental, ¿verdad? El punto de entrada de la aplicación es Index.js. Index.js carga Bootstrap. Bootstrap carga App.js, pero exponemos Hero. Entonces exportamos el lugar donde comienza el valor empresarial. ¿Por qué no App? Porque App es útil para nosotros. Si queremos cargar solo ese componente héroe como lo hicimos en este 8081. En 8081 cargamos solo esa aplicación de características para que el equipo de desarrollo pueda trabajar dentro de su aplicación de características agnóstica. Entonces el equipo de desarrollo puede usar un servidor de desarrollo y trabajar en su pequeño mundo sin nada más, ¿verdad? Entonces esto nos permite tener este pequeño mundo cerrado solo para esta característica. Pero cuando exponemos Hero, porque esta es la cosa que va a ser consumida por otras aplicaciones. Otra cosa que es genial usar aquí, porque, ya sabes, tienes uno, dos, tres pasos, tres módulos que se cargan básicamente solo en desarrollo. Y eso significa que puedes agregar un montón de tus módulos de desarrollo, código de desarrollo, cualquier cosa que te gustaría usar para el desarrollo, puedes inyectarlo en esta área. Un ejemplo, si tu empresa usa un tema especial y ese tema siempre se va a cargar en otro lugar porque se reutiliza. Tu componente héroe no necesita importar el tema porque el tema se va a dar de manera holística en el resto de la aplicación. Pero también puedes importar esa capacidad de tema en el app JS. Esto no se va a compartir, pero cuando sirvas la aplicación en desarrollo, se va a cargar. El tema como ejemplo, otro ejemplo podría ser la localización o también podría haber otras cosas. Entonces ahí es donde esta configuración es muy útil. Nuevamente, el único lugar donde valoramos los cuatro pasos es en el núcleo. El núcleo es la única aplicación que va a cargar todos los pasos hasta app JS, ¿de acuerdo? Y ahí es donde no queremos tener ningún entorno de desarrollo. De acuerdo, tenemos Hero.

Creo que expusimos Hero. Aquí, también podríamos importarlo porque este remoto nos dice dónde se encuentra el módulo. No necesitamos hacer nada aquí porque Hero, perdón, no módulo, biblioteca. Hero es una biblioteca. Pero esos módulos expuestos son algo diferente. Son cosas que nos gusta importar. Así que básicamente iríamos aquí y porque también sabemos, podemos decir import Hero, como componente Hero de, okay, ¿qué? Como, hero/Componente Hero. ¿Cómo construimos eso? Hero es el nombre de la biblioteca que ya definimos en la configuración de webpack del núcleo, lo nombramos Hero, okay? Y en webpack del Hero, exportamos un componente Hero. Exportamos el componente Hero y por eso estoy haciendo /Componente Hero. Y luego aquí, nuevamente, podría ser, podría mantenerme fiel al nombre y también puedo nombrarlo Componente Hero y ponerlo aquí mismo. Y acabamos de introducir un nuevo React. Introdujimos un nuevo componente React que se sirvió desde otro lugar. Veamos si tenemos más suerte. Permítanme verificar. Está ejecutándose en 8080. Ahí está el 8080. Parece estar bien. Está disponible, abrir en el navegador. Veamos si funciona. Voy a, okay, solicitud incorrecta. Oh, okay, esto es, las solicitudes incorrectas generalmente provienen de GitHub en sí. Y como vemos, no hay errores en el servidor de desarrollo. Así que lo intentaré de nuevo. Okay. Okay, ahora carga. Probablemente tenga un error en algún lugar. Okay, tenemos un error. Me niego a ejecutar el script. Bien, porque es inicio de sesión. Hay una redirección. Necesito hacer esto público. Bien, público. Ambos puertos son públicos. Puedo recargar. Si ustedes, oh, funcionó. Oh, es hermoso cuando haces algo de código y simplemente funciona desde el principio. Aquí también funcionó. Okay.

Permítanme hacer una pausa para leer sus preguntas. Y si tienen preguntas, siéntanse libres de escribirlas en el chat. Bien, enfrentando la pregunta. Si algunas de las aplicaciones no están disponibles, ¿cómo podemos manejar este error con modificaciones? Voy a llegar a eso. Estoy mirando el tiempo. Tenemos otra hora. Creo que lo lograremos. Hasta ahora mostramos cómo usamos, no este, este. Mostramos cómo usamos remotos que se declaran estáticamente dentro de la configuración de Web. En un momento, les mostraré cómo pueden hacerlo de forma dinámica. Vamos a eliminar este remoto y vamos a usar nuestro propio JavaScript para, vamos a comunicarnos con el complemento de configuración de Web. Le diremos, hey, Configuración de Web, hay un remoto del que tengo conocimiento y deberías usarlo. Y básicamente eso es el objetivo final. Así es como obtienes la flexibilidad para no preocuparte. Ahí es donde brilla el tiempo de ejecución completo, la federación de módulos vale la pena. Aquí es donde brilla porque si se declara estáticamente en la configuración que, hey, hay un servidor de compilación según sea necesario, ¿verdad? Pero si podemos eliminar esto y hacerlo dinámico, eso será increíble. Y te lo voy a mostrar. Ahora, vas a tener ese código para llevártelo a casa. Al menos una versión muy, muy simple. También preguntaste sobre errores. Si estás usando React, quería decir eso de todos modos. Recomiendo encarecidamente envolver esa inyección en un límite de error porque lo que React hace cuando hay un error, toda la aplicación se bloquea. Pero si hay un error dentro de un módulo federado, entonces si tienes un límite de error, sabes que algo sucedió, puedes decidir qué hacer con eso. Y si no hay nada que puedas hacer al respecto, solo esa característica se bloqueará, pero el resto de la aplicación seguirá funcionando. ¿Cómo haces el enrutamiento con el estado de URL y el intercambio? Voy a hablar sobre el enrutamiento, Lars. Cuando lleguemos, bueno, después de terminar con las dependencias, vamos a pasar a la comunicación, mencionaré las rutas. También puedes no nombrar explícitamente tus componentes expuestos con un punto. Gracias, Ricarta. Hay muchas cosas que una variación modificada hace posible. Ahora hay, se me olvida encontrar mi cursor. Hay un montón, solo hay algunas opciones de configuración. Exposes, nombre de archivo, biblioteca, tiempo de ejecución, blah, blah. Solo algunas opciones, pero hay mucho que puedes hacer con ellas. Es absolutamente asombroso, las combinaciones de cada una. Así que gracias por mencionarlo. Creo que esto es útil para todos los demás. Siéntanse libres de echar un vistazo. Ricarta, eres genial. Okay. No veo a nadie escribiendo, así que sigamos adelante. Oh, sí. Aquí es donde estaba. Así que tenemos esta aplicación. Voy a recargarla porque quiero ver la red. ¿Qué está sucediendo en la red? Echemos un vistazo. Así que primero, ws, esto es un WebSocket para el servidor de desarrollo. No necesitamos preocuparnos por eso. Esta es la página HTML. Oops, no quería hacer doble clic. El paquete principal React2 está de vuelta, no nos importa eso y hero. Pero la cosa es, este es el runtime de JavaScript. En main.js, este es un paquete grande.

Y es grande porque todo React está aquí. React está aquí y react está aquí. Entonces cada aplicación empaqueta su propio React y ReactDOM. No queremos eso. Realmente no queremos eso. Lo que queremos es que nuestra aplicación en su totalidad solo use una instancia de React. En primer lugar, no puedes ser serio acerca de tener dos instancias de React en una aplicación. Es imposible. Por lo general, no lo quieres. Entonces, para solucionar esto, le diremos a ReactDOM le diremos a Module Federation que tenemos ciertas comparticiones, ¿verdad? Entonces tenemos remotos, pero también tenemos bibliotecas compartidas. Bien, veamos. ¿Qué se comparte? Entonces, lo primero es absolutamente React es lo que recomienda el autocompletado. Y para React, se te dan algunas configuraciones. No tengo estas configuraciones. Nuevamente, podría mostrarte paso a paso y mostrarte cómo no usamos la configuración, pero voy a omitir ese paso. Voy directo al grano. Entonces, la versión requerida es 18.1.0, ¿verdad? Creo que eso es lo que tenemos en package.json. 18.1.0. Ahora, fíjate en esto. En la versión semántica, podemos hacer una versión estricta y decir que requiero 18.1.0. Eso significa que esta es la versión que quiero tener, y ya está. No quiero tener ninguna otra. Luego puedes hacer esto. Esto lo bloqueará a la versión menor. Entonces lo que funciona es 18.1.0, 18.1.1, y cualquier otro incremento de parche está bien. O podemos decir que cualquier incremento menor está bien. Eso significa que 18.1.0, 18.1.1, pero también 18.2, 18.5, 18.10, 18.1 mil. Cualquier cosa que esté dentro de la versión principal 18 se aceptará como una versión válida siempre y cuando no sea inferior a 18.1.0. Entonces 18.0.0 no es adecuado. Entonces el mínimo es 18.1 y cualquier cosa por encima dentro de 18. Eso es, en resumen, cómo funciona la versión semántica. Entonces le estamos diciendo al runtime que estamos compartiendo React 18.1.0. Yo uso lo mismo, ve 18.1.0, el mismo signo para que lo esté fijando, que lo esté manteniendo flexible, lo estoy acotando con una versión principal, pero las versiones menores y de parche son flexibles. Lo mismo ocurre con React DOM.

De acuerdo. Entonces chicos, aquí es donde lo acelero un poco en interés del tiempo. Me encantan sus preguntas. Espero que tengan muchas más preguntas. Eso sería mucho más divertido, espero. Entonces tenemos esto en webpack-config, el otro. Esto es hero, ¿verdad? Tenemos lo mismo. También necesitamos decir esto que estamos compartiendo estas bibliotecas. Y si vuelvo a cargar, vuelvo a cargar, puertos. Intenté documentación. Y no mostró cómo puedo mantener los puertos. Muestra cómo siempre puedo asignar tableros, pero no cómo puedo mantenerlo en público. Eso probablemente valga la pena mencionarlo en GitHub. De acuerdo, estoy recargando. De acuerdo, mira, es diferente, ¿verdad? Ahora tenemos Vendor's Node Modules React Index.js, ¿de acuerdo? ¿De dónde viene esto? Vamos a ver. Esto viene del puerto 8081. Ahora veamos React DOM. ¿Cuál es el puerto 8081? Esto es muy interesante. Déjame ver qué es esto. Vendor's Node Modules. Oh, este es el JS runtime. Y eso viene de 8080. Entonces, tenemos dos tiempos de ejecución, pero también podríamos compartir ese. ¿De acuerdo? Pero centrémonos en React y React DOM. Básicamente, lo que esto significa, es que ahora ambas características están utilizando un solo React DOM. Y ni siquiera está utilizando el del núcleo. Está utilizando el del héroe. ¿Por qué? Si recuerdas cuando tuvimos ese primer ejemplo, cuando teníamos esa función de renderizado, renderizaba el héroe, y luego el núcleo, y luego el héroe de nuevo. Eso es porque el héroe fue importado primero. Pero, el runtime es lo suficientemente inteligente. Hay mucho que sucede allí. Hay un registro completo que el runtime está mapeando con todas las dependencias. Y podemos confiar en el runtime, creemos que es realmente bueno en eso, para elegir la mejor versión posible. Si tuviéramos 10 aplicaciones de características con 10 versiones diferentes, el runtime elegiría la mejor versión para nosotros. Entonces, podemos probar eso. Entonces, si instalamos, voy a intentar no instalar. Esto es héroe. Esto es héroe. Entonces, si digo que mi versión requerida es 1800, y está fija, ¿qué va a pasar? Voy a reiniciar. Yarn hero. De acuerdo. Puertos, necesito volver a habilitar eso. Mira, ahora tengo un poco de conflicto, ¿verdad? Una versión. Una aplicación requiere 1810. La otra requiere 1800. Y es una versión fija. De acuerdo. Entonces, ¿qué está sucediendo aquí? ¿Cuál está ganando? 8081 de nuevo, porque, bueno, sabemos que es 8081 porque está en package.json. Pero lo que quería mostrar, es que tan pronto como tengamos un conflicto, va a encontrar la mejor versión. Y va a elegir, una vez que Hero tenga una versión más antigua, necesito instalarla también. Una vez que Hero tiene una versión más antigua, el runtime va a decir, oh, semánticamente el núcleo tiene una mejor versión. Así que no lo cargaré desde Hero, lo cargaré desde un lugar diferente. Y esto es lo que hace esta importación dinámica. Esto es lo que esta importación dinámica nos ayuda a hacer. Permite que el runtime descubra el registro de versiones. Ahora he creado varias variaciones diferentes de cómo trabajamos con, cómo lo probamos, cómo probamos conflictos de versiones y cómo vemos cómo el runtime lo usa. Pero esto es algo genial. Sí, eso es correcto. También necesito tener el paquete grande ASAN. Esta es una biblioteca que realmente se carga. Lo genial es que puedes probar eso como tarea. Pero lo que quería llegar es que React es muy especial. Lo que mencioné anteriormente es que básicamente hay múltiples tipos de dependencias. Y este React solo puede estar en una página como una única instancia. Porque si lo piensas, React recibe todos los componentes y renderiza una única versión de la aplicación en memoria. Y solo para eso está React y React DOM que trabajan en cooperación para trabajar con todo el árbol. Pero necesita todo el árbol. No puedes actualizar una parte del árbol con una versión diferente de React. Entonces, con eso dicho, porque solo tenemos una versión de React, vamos a tener que decir que React es un Singleton. Entonces eso le dice al runtime, eso le dice al runtime que cualquiera que sea la versión es la mejor cuando comenzamos porque podemos cargar cosas dinámicamente. Nunca puedo aceptar una versión diferente. Solo puedo tener siempre una única versión. ¿Por qué? Porque si tenemos un tipo diferente de dependencias, como LowDash, como Ionic, como funciones de fecha, ¿verdad? Si tenemos diferentes tipos de dependencias, estas dependencias se pueden cargar en múltiples versiones. Entonces, funciones de fecha, en la versión... Si tienes dos versiones principales, versión 1 y versión 2, o por ejemplo, funciones de fecha, se cargarán juntas. Estarán en la misma caja, sus memorias no chocarán, pero se cargarán juntas porque una aplicación necesita la versión 1, la otra aplicación necesita la versión 2. Y porque decimos que requiere la versión, así es como lo sabemos. Pero tan pronto como decimos que se cargó una versión singleton, el runtime va a decir, no, no voy a cargar la otra versión. Solo puedo tener una. React es un ejemplo de tal biblioteca, pero también bibliotecas como, Style Components. Porque Style Components siempre tiene un proveedor que mantiene el tema y funciona con todo ese CSS en memoria y todas esas cosas. Entonces, solo puede ser un... Rastrea todas las dependencias y, para ser honesto, ni siquiera conozco los detalles internos, pero Style Components es una biblioteca neural que debe ser un singleton. Porque técnicamente, algunas versiones de los enrutadores se pueden instanciar varias veces siempre que tengas lo mismo... Como en ReactR es la instancia de la historia. Pero en esencia, deberías tener al menos esa... Esa historia debería ser única. Si es posible, todo el enrutador de react, porque no se trata solo de si puedes tener múltiples versiones en una página, es importante que puedan compartir datos. Si estás en el módulo en dos versiones, básicamente lo que obtienes son dos cierres, dos asignaciones de memoria separadas. Entonces no quieres, necesitas poder manejar eso.

Necesitan poder compartir data. Entonces, si comparten data, están bien. Pero eso es lo que generalmente un Singleton no permite múltiples versiones porque múltiples versiones significa que no comparten data. En React, necesitas compartir contexto y el contexto debe estar dentro de la misma asignación de memoria. Ahora, sé que me estoy adentrando un poco en esto pero es muy importante conocer tu Singleton y qué bibliotecas deben cargarse solo una vez. Límites de Sierra, de acuerdo. Voy a tomar un respiro para leer los comentarios y preguntas. Si la instancia del héroe no está ejecutando la aplicación principal tampoco muestra el texto de bienvenida. Y Lars tenía razón. Aquí es donde hablamos de los límites de error. Entonces no se está ejecutando, lo que significa que obtienes un error ya sea un 404 o 500 lo que sea que se muestre allí pero no podrás cargar esa aplicación de script. Y cuando no puedes cargar la aplicación de script eventualmente dará un error. Nada va a funcionar. Pero si tienes un límite de error puedes decidir qué hacer con esa información de que tienes un error. Tal vez puedas señalar a una ubicación diferente o simplemente mostrar un mensaje especial. Y gracias por hacer esta pregunta. ¿Puedo usar otra biblioteca diferente por ejemplo, Angular en otro módulo. Hace un tiempo, fui invitado a un podcast y creo que la mayoría del podcast fue sobre eso porque sentí que era difícil de entender. Entonces, si la gente dice, oh, son micro-frontends, me dan que es democracia o democratiza el desarrollo. Puedo hacer lo que quiera. Puedo introducir mis dependencias. Puedes introducir dependencias, las mejores dependencias pero habrá algunos acuerdos contractuales. Si usas React y Angular, ahora no pensemos en micro-frontends. Pensemos en una aplicación de una sola página en un SPA, ¿usarías Angular y React al mismo tiempo? Y generalmente la gente no hace eso. Pero luego puedes decir, pero, pero ¿por qué? ¿Y debería ser libre de elegir lo que quiera? Y es cierto, deberías serlo, pero también hay límites a nuestra libertad, ¿verdad? Puedes hacer lo que quieras hacer. No sugiero eso, porque eso creará una gran penalización para el usuario. ¿Cómo compartes memoria? ¿Cómo compartes estado entre dos aplicaciones? ¿Cómo compartes el estado de navegación entre dos aplicaciones? Se vuelve muy difícil. Ahora llegamos al punto donde posiblemente la pregunta fue posiblemente debido a una migración. Entonces tal vez quieras migrar la aplicación de react a Angular o de Angular a React. Y luego cuando quieres usar el patrón estrangulador, entonces migras secciones de la aplicación y está bien. Eso puede funcionar técnicamente, Milo Federation no le importa lo que hagas porque siempre es JavaScript. Milo Federation solo te ayuda a cargar el JavaScript desde la nube. Y si puedes hacer que funcione. Entonces, de alguna manera, tus características son tan agnósticas, no les importa ese estado compartido. O si quieres gestionar el estado compartido a través de un backend o microservicios, sí, eso puede funcionar, ¿verdad? Se te permite hacer eso. Pero generalmente esos acuerdos contractuales como el framework, el enrutador. Entonces usas un enrutador, no dos enrutadores. Y puede haber otros acuerdos contractuales en los que el equipo pueda ponerse de acuerdo, como la localización. Quiero decir, sí, por supuesto, puedes tener múltiples bibliotecas de localización. Pero ¿por qué cargar múltiples? Por lo general, las bibliotecas de localización son grandes. ¿Por qué cargar múltiples bibliotecas de localización si no es necesario? Algunas de esas decisiones, voy a decir, de cara al público, ¿deberían seguir siendo uniformes en toda la solución? Cosas que deberían ser elección del equipo es cómo desplegar en la infraestructura. Quiero decir, los equipos, las organizaciones habituales simplemente eligen una nube. Pero ¿por qué no elegir varias nubes? Tal vez un equipo quiera desplegar en AWS, o AWS quiere desplegar, el otro equipo quiere desplegar en Google o Azure. Técnicamente eso está bien, eso debería estar bien. Estará totalmente bien. Un equipo quiere usar GitHub o CI o CircleCI o Jenkins. Eso está totalmente bien. Si quieres usar JS, si quieres usar diferente, lo que sea, ya sabes, puppeteer, no sé diferentes configuraciones de testing, diferentes configuraciones de testing, todo eso sucede de alguna manera de forma aislada. No es de cara al público. Creo que eso es genial, lo que el equipo se sienta más cómodo. Si quieres usar TypeScript, o si quieres usar algo más, no quieres usar TypeScript, esa debería ser la elección del equipo. Nuevamente, las empresas pueden tener políticas, es posible que debas cumplir con ciertas políticas, pero esa es la libertad que funciona bien. Ahora, volverse loco con diferentes frameworks puede ser contraproducente. De acuerdo, todos los módulos son independientes entre sí, pero cargas código de framework antiguo. Sí, exactamente. Entonces, está bien si usas tanto Angular como React cuando gestionas una migración gradual con un modelo de una aplicación monolítica. Se puede hacer, pero debe haber una buena razón. Estoy totalmente de acuerdo. Ahora, una vez que hayas optado por MicroFrontends, a menos que quieras migrar a un framework completamente diferente, a una arquitectura completamente diferente, MicroFrontends con Model Federation es una gran inversión en migraciones futuras. Te daré un ejemplo sencillo. Moment.js, la biblioteca, ya no se mantiene. En algún momento, dijeron, oh, hemos terminado. Ya no lo mantendremos. Es una biblioteca antigua. Hay otras alternativas más pequeñas que deberíamos usar. Entonces, en ese punto se vuelve un poco más difícil actualizar Moment, pasar de Moment a DateFunction o algo más para un gran monolito, ¿verdad? Porque tienes que reemplazar un montón de cosas. Si el equipo fue inteligente y si el equipo trabajó con abstracciones desde el principio y creaste tu propia abstracción, entonces solo reemplazas la abstracción, eso es genial. Pero la mayoría de la gente no hace eso. En este ejemplo, Module Federation es fantástico porque puedes actualizar característica por característica. Tu navegación ya no usará Moment. Usará DateFunction. Sí, cargarás DateFunction y Moment por el momento, pero también obtienes, el punto sobre el patrón de estrangulador es que comienzas o migración gradual, comienzas a migrar y comienzas a conocer tu nueva aplicación migrada lo antes posible, ¿verdad? Obtienes retroalimentación, tal vez olvidaste migrar una corrección de errores. Tal vez no les gustó la nueva interfaz de usuario, tal vez, ya sabes, quién sabe. Pero la capacidad de obtener esa retroalimentación temprana es, creo, una de las mejores cosas que obtienes de una iteración modular. De acuerdo, Joe tiene que salir por el recuerdo, no sé si todavía estás con nosotros, gracias por unirte, Joe. Entonces, en la situación en la que cargamos el módulo principal en un iFrame amigable, y luego escapamos para renderizar en la ventana principal. De acuerdo, ¿se puede controlar dinámicamente la ventana en la que deben cargarse los módulos del héroe cargando un script adicional en el padre? Entonces, la pregunta que creo que viene de Sharkey the dog es trabajar con micro-frontends si están dispersos en varios marcos y iframes. Y eso nos lleva a JavaScript en lo que estás haciendo. Y generalmente con JavaScript, es cómo se configuran tus políticas de seguridad de contenido. Si se están cargando desde diferentes dominios y a través de la política principal, realmente depende de cómo se configura la seguridad. Por lo general, es muy similar a un sistema de red. Por lo general, no confiaría en la comunicación entre marcos. Hay límites. Puedes enviar mensajes y hacer que funcione porque al final del día, sigue siendo JavaScript. Pero no creo que lo haría, a menos que sea absolutamente necesario. Si tienes una aplicación que usa marcos y quieres migrar gradualmente a micro-frontends, entonces tienes que hacer lo que tienes que hacer, ¿verdad? Entonces puedes... Lo único es que debes encontrar una forma de compartir memoria, de asegurarte de que algún tipo de estado sea accesible desde todos los marcos. Y si puedes hacer eso, entonces estás bien. De acuerdo. Preguntas increíbles. Técnicamente tenemos 30 minutos y mucho que compartir.

De todos modos, lo que quería, las otras cosas que quería compartir con estas partes, voy a decirte, porque es más rápido. Como iba a hacerlo con el trabajo con estas dependencias, como React y demás, al cargarlas, como dije, van a, si están en conflicto y no son singletons, van a funcionar, se van a cargar dos veces, cada una en una versión diferente. Y tengo un ejemplo para eso, en realidad usé funciones de fecha. Así que déjame tratar de presentarlo. Voy a crear, en uno de los componentes, voy a agregar una fecha, ¿verdad? Algo muy simple. Voy a formatear alguna fecha. Y de nuevo, voy a copiar y pegar algunas de estas... Déjame ver, en el núcleo de la aplicación, quiero usar funciones de fecha 2.1, y en hero, voy a usar funciones de fecha 2.2. Así que aquí no tenemos, técnicamente, un conflicto de versiones, ¿de acuerdo?, y voy a crear un nuevo componente aquí. Lo voy a llamar today, solo para mostrar la fecha de hoy, así de simple. Y para mostrar la fecha de hoy va a ser algo como esto. Así que el componente es today, sea lo que sea hoy, hoy es ese día. En cualquier componente de hero, voy a decir, voy a crear un componente llamado birthday, nuevamente, es una oportunidad para trabajar con el tiempo, voy a colapsar la terminal. Solo una oportunidad para trabajar con el tiempo. Y esto definitivamente no va a ser mi cumpleaños. De acuerdo, así que tenemos una fecha diferente de la función de fecha, así que esto es 12-12-2022. Para ser honesto, esta fecha fue autocompletada por este pequeño amigo llamado Co-Pilot. Entonces, mi cumpleaños está en, va a ser en cierto número de días, ¿verdad? Esta es una diferencia. Ahora, déjame ver. Probablemente debería, también exportar esto. Tenemos el componente hero y también tenemos birthday. De acuerdo, así que esto es para que podamos inyectarlo. En cuanto a las dependencias, voy a mostrarte un pequeño truco. A veces podemos hacer esto en la parte superior. Voy a requerir packageJSON. Y luego voy a ir a shared y simplemente hacer esto, extender las dependencias de packageJSON. Entonces, lo que va a hacer es recorrer packageJSON, va a mirar todas las dependencias aquí y verás, las funciones de fecha son la versión 2.2. Y simplemente va a copiar todas las dependencias a shared. Y no necesito preocuparme por mantener esta lista compartida. Pero si quiero tener configuraciones que estén fuera de solo la versión y el nombre, como aquí tenemos Singleton, entonces mantendré React y ReactDOM, ¿verdad? Anularán los de las dependencias. Una advertencia, a algunos equipos realmente no les importa. Donde están las dependencias o las dependencias de desarrollo. Si tienes esto, entonces no quieres empaquetar dependencias que pertenezcan a Node.js. ¿Verdad? Entonces, las bibliotecas de Node.js, no quieres mantenerlas aquí porque ¿por qué las empaquetarías, verdad? ¿Por qué empaquetar cosas que no son útiles? También puedes tener problemas con los internos de webpack porque, por ejemplo, Path o Fs, ya sabes, esos no son HTTP. No están disponibles cuando te diriges a la web, ¿verdad? Así que no quieres meterte en todo esto. Quieres mantener tus dependencias correctas. Si tu aplicación es de pila completa, lo alabo, desearía que todas las aplicaciones fueran así. La pila completa es increíble. En ese caso, es posible que tengas dependencias reales que pertenezcan al backend. Entonces, si tienes eso, simplemente puedes extender esto. Esta es una versión simple. Podemos extenderla un poco y puedes crear tu propio resolutor donde puedes poner en lista negra o podrías, si no pones en lista negra, puedes tratar de averiguar si una dependencia es una dependencia no. Y luego haces eso y filtras y estás listo, ¿verdad? Poner en lista negra es lo más fácil. Lo siento, tuve que dejar a Ricardo. Muchas gracias por unirte. De acuerdo, esto es algo que también podemos pegar en un webpack del componente hero, ¿de acuerdo? Justo aquí, haciendo lo mismo, packageJSON en la parte superior. De acuerdo, lo mismo. Y este es un momento en el que reiniciamos los servidores. Reiniciamos los servidores, pero creo que hice todo lo que quería hacer. Tenemos today, y en la aplicación, obviamente, probablemente querría importar. Importar today desde, y esto va a ser today así, ¿de acuerdo? Y también quiero importar birthday. De acuerdo. Así que importé today, que usa la versión local de las funciones de fecha, y birthday que usa la versión de hero, ¿verdad? Así que hoy, hola mundo, esta es una aplicación de React. Y déjame ver, hoy va a ser una capa div. Así que voy a poner today en la parte superior, ¿por qué no, verdad? Esto no es una clase de diseño, porque fallaría birthday, en la parte inferior. Oh, ¿esto va a funcionar? Bueno, si no cambio los puertos, no lo hará. De acuerdo, espacios de código, ¿te congelaste? No, está bien. Y necesito, ups, yarn. Servir, porque estoy en el paquete app core, y yarn 8080, gracias. Yarn hero, porque estoy en la raíz. De acuerdo, ambos se están ejecutando, son privados. Sería mucho mejor si esto siempre fuera público, de acuerdo. Está funcionando, de acuerdo. Así que tenemos today, es el 9 de junio de 2022 y si es tu cumpleaños, si naciste el 12 de diciembre, entonces tu cumpleaños está en 185 días, solo para que lo sepas, si conoces a alguien más, están a seis meses de su cumpleaños. Así que echemos un vistazo a las funciones de fecha. Tenemos funciones de fecha y ahí es donde tenemos esa duplicación, ¿ves eso? Así que tenemos funciones de fecha y tenemos funciones de fecha dos veces. Una vez es desde el puerto 8081, la otra vez es desde el puerto 8080. Eso es porque tenemos una configuración diferente. En una aplicación, decimos funciones de fecha hasta la 2.1. Eso significa 2.1 en las versiones de parche y nada más. Mientras que esta dice 2.2 en todas las versiones menores que son mayores o iguales a 2.2. Y tenemos un conflicto ahí. Porque tuvimos un conflicto, el tiempo de ejecución dijo, oh, está bien, puedo trabajar con eso. Voy a cargar ambos. Van a ser la misma caja. No van a chocar. Así que hoy esta fecha se construye con una versión de la biblioteca. Esta se construye con la otra versión de la biblioteca. Y así es como gestionamos eso. De acuerdo. Así que hagamos esto. Este es el ejemplo, básicamente dos y tres. Anotémoslo. De acuerdo, hemos terminado. Hasta ahora, creo que hemos logrado mucho. Pudimos crear la federación de módulos, dos aplicaciones, una aplicación simple. Pudimos inyectar. Pudimos trabajar con dependencias. Vimos algunos de los problemas comunes en soluciones con dependencias. Creo que esto debería ser una buena cantidad para comenzar.

Y ahora, quería concluir con las dependencias. Como prometí, quería mostrarte cómo puedes cargar las dependencias de forma dinámica. ¿Tenemos alguna pregunta hasta ahora? ¿Con lo que acabamos de cubrir? Oportunidad. Lars. Entonces dijiste que tus dependencias están en DevDependencies, pero esparces las dependencias. En realidad, esparzo estas dependencias que son dependencias de Azure. En DevDependencies, verás que las tengo a nivel de espacio de trabajo, que es un Webpack, DevServer, y así sucesivamente. No quieres compartir estas porque se ejecutan en esta computadora, en el servidor, en CI. En el paquete, esto no se está... Miras en el nivel superior de los paquetes. Eso es lo que pensé también. De acuerdo. Nuevamente, la razón por la que estoy usando Lerna es, y lamento confundirte, pero estoy usando Lerna para que sea más fácil, para que tengas todo en un solo repositorio, para que no tengas que pensar en múltiples repositorios. En la vida real, no usaría Lerna para tu proyecto. Y la razón es bastante sencilla. A medida que tu aplicación crece, tu repositorio de .git va a ser enorme, y luego vas a crear PR, y va a haber conflictos de fusión. Y luego Lerna es bueno para compartir. Como microfinanzas, sí, quieres compartir un poco, pero también quieres tener un poco de propiedad. Y si todo está en un solo repositorio, todas las posibles variantes de bibliotecas de pruebas, ejecutores, scripts de CI y todas esas cosas, se vuelve confuso, ¿verdad? Porque quieres dar esa libertad, y si la libertad se ejerce en un espacio común, es confuso. Al igual que si tuvieras a 10 personas hablando 10 idiomas diferentes tratando de comunicarse, pero no pueden, ¿verdad? No es muy útil. Pero lo bueno aquí es para las características, usaría y prefiero, siempre sugiero usar repositorios Git dedicados por característica. Código compartido. El código que realmente quieres poner a disposición de todos los demás, la parte compartida. Entonces, donde tienes una lógica especial para comunicarte entre aplicaciones, o donde tienes una lógica especial para cargar traducciones, o cosas así. En algunos casos, incluso la autenticación, aunque eso también puede ser dinámico. Así que esos son o el seguimiento y etiquetado, ¿verdad? Esas pueden ser aplicaciones de características, pero también pueden ser bibliotecas, si no son funcionales, si los usuarios realmente interactúan con ellos. Realmente depende de cómo los proyectos y los equipos usen eso. He visto, por ejemplo, que el seguimiento es una aplicación de características, eso significa que soy una aplicación de características, soy totalmente agnóstica y hago mi cosa. Puedo exponer bibliotecas, otros pueden usarlas, o puedo hacer mi propia cosa, eso es una aplicación de características. O una biblioteca es, estoy destinada a que otros me usen y no estoy haciendo nada automáticamente. Mi propósito es que otros proyectos me usen, pero no tienen que hacerlo. Esa es la diferencia, por eso dije, técnicamente esto es fácil de entender, creo, espero. Los arquitectos y los arquitectos de soluciones pueden tener un poco de dificultad para poner las cosas en orden, especialmente por primera vez a medida que se construye esa experiencia, pero la mejora y el cambio principales, y sabemos cómo puede ser difícil el cambio, pueden estar a nivel organizativo. De acuerdo, dejaré de predicar sobre eso porque siempre hay una historia sobre todo lo que predicamos, y esto puede volverse realmente complicado. De acuerdo, vimos eso, y como dije, el siguiente paso es crear un cargador dinámico. Ahora, voy a hacer eso en el núcleo, así que tenemos remotos, simplemente voy a comentar esto. Estoy haciendo esto, para que tengamos algún tipo de historial, así que lo comenté, y probablemente necesitemos reiniciar el servidor para esto. De acuerdo, y obviamente, fallaría si estás intentando, así que esto es público, privado, bueno, público. Está probablemente va a fallar. No, va a fallar, porque no sabe cómo cargar a Hero. Así que trabajemos desde aquí, arreglemos esto. Entonces, la aplicación está usando estas dos bibliotecas. Sí, ya no puedo usar este nivel de importación si uso cargadores dinámicos, así que voy a recurrir a algo más. Voy a crear un nuevo componente, lo llamaré cargador. Lo tengo listo, chicos. No voy a escribirlo. Confíen en mí cuando digo que probablemente tiene un par de cientos de líneas de código. No, casi 100, pero esta es una versión simple. Y te lo voy a explicar para que sepas qué está sucediendo. En primer lugar, vamos a omitir esto, vamos a omitir este paso. Voy a hablar de eso más tarde. Entonces, ¿qué necesitamos hacer? Necesitamos crear un script, ¿verdad? Necesitamos crear un script. Debería ser síncrono. Y adjuntamos un escucha en la carga. Entonces, cuando se carga, decimos que estamos listos. Si hay un error, decimos, oh, hubo un error. Y eventualmente, cuando desmontamos, podemos eliminar la etiqueta de script, ¿verdad? Eso es simplemente trabajar con etiquetas de script. Vamos a usar esta función de cargador. Entonces, la función del cargador hace esto, utiliza este hook para importar la fuente. Y si estamos en desarrollo, ahora en el paso de compilación, este bloque en producción, este bloque se eliminaría porque Webpack va a saber estáticamente que el entorno es producción, así que puedo eliminar este código, eliminación de árbol. Pero estamos trabajando en desarrollo y vamos a ver la carga de la característica y un fallo al cargar la característica si falla, ¿verdad? Como ayuda. Utilizamos suspense y eso significa que cuando se carga, vamos a activar esta función que se comunica con la iteración del módulo. Así que eso es lo que dije que mencionaría más tarde. Esto realmente no está. No creo que lo encuentres en la documentación, pero puedes encontrar rastros de estos, puedes encontrar rastros de estos comandos o tal vez incluso funciones muy similares en varios ejemplos en línea, ¿verdad? Incluso creo que la federación de módulos, una organización de GitHub que es propiedad de Zack Jackson, creo que puede haber creado algo así también. De todos modos, todo el asunto es que llamamos a estas funciones especiales que solo están disponibles porque Webpack registró que nuestro código las necesita. No puedes llamar a esto para console, esto no está en el ámbito global. Webpack analiza tu código y dice, oh, necesitas Webpack en su compartición, este es un método especial. Así que decimos, está bien, voy a, nuevamente, en una compartición hay algo llamado scope. Siempre usamos el scope completo, pero también puedes crear scopes adicionales. No te lo he mostrado porque siento que eso en su mayoría no es necesario. El scope completo es suficiente. Pero si necesitas cargar módulos compartidos en diferentes espacios de nombres, también puedes hacerlo. Luego los espacios de nombres predeterminados, predeterminado obvio. Así que inicializamos esa característica a través de esta línea. Y luego decimos Windows code. Si recuerdas cuando dije, vamos a un paquete, lo siento. No paquete, me refería a la configuración de Webpack. Y lo llamamos hero, ¿verdad? Eso significa que va a haber un objeto llamado window.hero. Y así es como funciona. Así es como empaquetamos los módulos de JavaScript. Y eso también es configurable, si cambiamos cómo funciona esa biblioteca a través de la configuración, hay documentación para eso. Esto está definitivamente fuera del alcance de esta introducción. Pero podrías cambiar completamente cómo se empaquetan las características. Nuevamente, no voy a tocar eso, pero hasta ahora, solo para que sepas que obtenemos ese contenedor, ahora que es el runtime. Y luego inicializamos, ¿verdad? Los ámbitos de compartición de Webpack en el ámbito de compartición predeterminado, inicializamos ese contenedor, esa etiqueta de script que recibimos, llamamos al método init de ese script y lo fusionamos con ese espacio de nombres predeterminado. Entonces, eso es cuando dije, cada característica remota que cargas va a fusionar runtimes, va a fusionar registros de dependencias, va a fusionar la información que comparten a medida que se introducen. Y esto es esa fusión, inicialización, ¿verdad? Finalmente, obtenemos el módulo y lo devolvemos, es un método de fábrica.

Ya sé que esto suele ser mucho para la mayoría de las personas y puedes simplemente copiar esta parte, será suficiente para la mayoría de las aplicaciones. Bien, esta es la aplicación, ahora viene la parte de cómo la cargo. Voy a volver a la aplicación, de nuevo, Cargador, necesito ese Cargador, Cargador. Ya no puedo instanciar hoy y cumpleaños de esta forma, pero puedo usar el Cargador. Y el Cargador tiene algunas propiedades como source, library y mod. Bien, empecemos con source. Source va a ser, voy a robar eso de la configuración de Webpack, no esta. Esta es la source, aquí, hero.js. Así que esta es la dirección. ¿Y ahora qué más? Tengo una library. Si recuerdas, se llama Hero. Es importante que nombremos las cosas como se llaman, esta aquí. La library se llama Hero. Y el módulo, no lo usé, así que no uso module porque module, definitivamente está reservado, pero va a funcionar bien. Pero para dejarlo claro para otros desarrolladores, esto no es module.export. Esto es, no quería confundir a nadie con eso. Así que no es el componente Hero que usamos hoy, ¿verdad? No, cumpleaños. Bien, cumpleaños. Sí. Bien. Y va a ser /cumpleaños. Así que este es cumpleaños y eso reemplaza a este. Bien. El cumpleaños se queda hoy porque eso es local, lo importé aquí localmente. Pero el componente Hero, el componente Hero tiene que estar en minúsculas. El mismo source, solo que el componente es... Bien, el mismo expose que usé antes. Bien. Es una de esas cosas. Veamos si esto funciona. Se está cargando. Mientras se carga, voy a verificar que realmente lo tenga. Bien, está en ejecución y el puerto es público. Pero veo, no recuerdo si reinicié. Era core, así que voy a reiniciarlo. Y cambiaré a público, en caso de que también estés siguiendo. Bien. Esperando, ¿está esperando a todos? A veces hay inconsistencias. Bien, a veces tenemos que darle tiempo. Pero estamos cerca, gracias Michael. Me alegra que haya funcionado para ti localmente. Voy a darle tiempo. Parece que todavía se está poniendo en marcha. Oh, ahí está. Oh, ahí vamos. Así que la forma en que sabemos que funciona son esos mensajes que escribieron, los mensajes de estado. Verás, sabes, se está cargando una característica, cargando una característica, cargando la aplicación, bam, se muestra aquí. Así que acabamos de cargar dinámicamente un módulo. Cargamos algo que está almacenado en algún lugar estáticamente en la web en la nube y lo importamos en tiempo de ejecución. Así que imagina conectar esto con un CMS, como Contentful, por ejemplo, y permitir que las personas creen su propia aplicación como deseen, pasando configuración a cada característica. Es realmente notablemente poderoso lo que puedes lograr con esto. Bien. Voy a pausar con el código y antes de hacerlo, te debo este ejemplo, dos o tres, esto es cuatro. Bien. Vamos a recargar. Bien, voy a hacer commit de eso. De todos modos, quiero darte, como prometí, algunas cosas más. Bien. Déjame, déjame encontrar esa pantalla. Ve más despacio si es necesario.

Entonces, ¿cómo nos comunicamos, cómo nos comunicamos entre aplicaciones? Un enfoque común es utilizar el bus de eventos. Antes de hablar sobre observables y el bus de eventos, quiero decir que toda la idea de las microcaracterísticas es que, si puedes, por todos los medios, no te comuniques. Nunca va a suceder. No puedes eliminar la comunicación. Pero quiero desalentarte de crear acoplamiento, puntos de acoplamiento. Lo que estás haciendo aquí es escapar de las cadenas de un monolito. Estás creando algo independiente. Pero cuando creas acoplamiento, básicamente estás volviendo a un monolito. Deberías tratar de no hacer eso. La comunicación crea acoplamiento porque crea esa dependencia. Nuevamente, a veces tienes que comunicarte. El bus de eventos es una de las formas. Es genial porque es como disparar un evento y alguien escucha ese evento, escucha un desencadenador. Lo genial es que, nuevamente, me encanta cuando las cosas son agnósticas, cuando no les importa dónde están. Y los escuchadores generalmente son agnósticos, vas a decir, oh, quiero escuchar este evento de cambio de ruta. Y cuando alguien cambie de ruta, entonces voy a hacer una cosa. Voy a calcular algo y trabajarlo. Voy a enviar, voy a enviar una etiqueta al administrador de etiquetas o algo así. Y eso funciona, está bien, ¿verdad? Es hermoso. Básicamente elimina muchas de las dependencias. No necesitas bibliotecas especiales para eso porque los eventos se pueden usar de forma nativa. Y a medida que trabajas con MicroVerse, te sugiero encarecidamente que, si puedes hacer algo de forma nativa, lo hagas de forma nativa. No necesitas, no siempre necesitas usar bibliotecas para todo. Y a medida que los equipos se vuelven locos con las bibliotecas, puede ser, ya sabes, sigue siendo mucho JavaScript. Otra cosa genial acerca de los eventos es que pueden ser capturados por múltiples instancias, y lo haces sin ningún esfuerzo. Cualquiera puede asignar eventos. Puedes asignar lotes de eventos, grupos de eventos que puedes asignar, puedes crear cosas locas como capturar todos los eventos. Puedes hacer cosas locas, pero hay desventajas.

Entonces, ¿qué sucede si quieres disparar un evento pero el escuchador aún no se ha cargado? La característica a la que debería escuchar se retrasa un milisegundo y no captura ese evento. Por lo tanto, nunca estás seguro de si el evento que estás disparando fue consumido. Eso puede ser un problema o tal vez el evento se disparó varias veces, pero luego se carga una aplicación de características que desea conocer esos eventos. Y nunca va a conocer el historial. A veces quieres saber cómo se desencadenó ese evento desde la primera instancia en adelante, y se pierde ese historial, ¿verdad? Solo conoces pequeños mensajes como `pong, estoy aquí, evento pong`, pero no conoces el historial de pings y pongs anteriores. Eso puede ser un problema. Puedes solucionarlo. Puedes crear un sistema de escucha que diga: `oh, si nadie me capturó, entonces encola el evento`. Y cuando una aplicación de características que tiene un escuchador pasa, entonces lo dispara. Pero eso está lejos de ser perfecto. Eso no va a funcionar para todos los propósitos porque el primero lo verá, pero no los siguientes y puede crear problemas. Pero tengo problemas para cada una de estas soluciones. Puedes usar servicios. Hay bibliotecas de microcaracterísticas que se basan mucho en los servicios. Con servicios me refiero básicamente a funciones de código, ¿verdad? Puedes crear funciones que sirvan como puente de comunicación. Eso es a lo que me refiero cuando digo servicios. Y eso puede ser interesante. Incluso puede ser genial. Puedes tener equipos que se dediquen exclusivamente a los servicios o los servicios pueden pertenecer a esos equipos y ser dueños de esa unidad de negocio. Además, el problema es que crea dependencias. Hay una dependencia de un servicio. Y cuando hay diferentes versiones, eso crea un poco de un infierno de versionado. Puedes mantener tus propias versiones. Puedes tener la versión uno del servicio, la versión dos del servicio. Puedes hacer eso. Se complica. Como cofundador de la aplicación, te garantizo que los servicios se volverán complicados. Y una de las peores cosas que quieres tener es un sistema que requiera que las personas aprendan mucho. Tan pronto como te desvíes de los estándares, eso significa que a partir de ahora, requieres un aprendizaje adicional. Entonces, cuando incorporas a una persona a tu equipo, les llevará dos meses comprender cómo funcionan tus servicios, cómo funcionan tus servicios, versión uno, versión dos y otras versiones. Eso se convierte en un problema. Y los servicios terminan, me gustaría poder decirte un nombre, pero hay esta gran, gran empresa. Es una empresa enorme en Alemania. Es una de las empresas más grandes del mundo. Así que terminaron con servicios. Todo ese sistema realmente lleva, al menos, creo, la mediana es de dos meses para que una persona se incorpore y aprenda cómo usarlos. Es tan complejo. No estoy diciendo eso, no estoy tratando de asustarte, porque los servicios pueden ser muy limpios y hermosos, pero debido a esa dependencia que están creando, necesitas escapar de las incompatibilidades de versión, y eso puede ser problemático. La comunicación del lado del servidor, obviamente, quiero decir, eso está claro, ¿verdad? Mantienes algo en el lado del servidor, envías cosas, envías comunicación, con suerte, a tu nube y no a un servidor RESTful, y eso es útil. Eso es útil para cosas como esa pregunta sobre marcos, ¿verdad? Simplemente envías a un servidor y te comunicas de vuelta, pero debido a la latencia, obviamente es muy lento y las personas lo notarán. La regla general para la latencia es, mi regla general, son 200 milisegundos. Pero ahora mismo, las personas tienen en promedio de 30,000 a alrededor de 200,000 receptores en la retina, les toma alrededor de 150 milisegundos para que esa imagen se transfiera al cerebro, el cerebro reconoce, analiza la imagen y reconoce qué es. Por eso nuestro tiempo de reacción está entre 150 y 200 milisegundos. Vemos que algo ha llevado tiempo si supera los 200 milisegundos. Y si necesitas comunicarte con otra característica y lleva más de 200 milisegundos, los usuarios notarán que algo es lento, que algo está sucediendo, ¿verdad? Por eso la regla general para mí son 200 milisegundos. Tengo muchos de estos números que provienen de pasar años aprendiendo sobre psicología, para ser honesto. Creo que el desarrollo de UI es mucha psicología humana. El estado compartido, muy viable. No puedo decirte cuántas veces escuché, ¿por qué no usamos Redux? Puedes usar Redux. Redux soluciona algunos de los problemas, no tiene que ser el administrador de estado de Android, puede solucionar algunos de los problemas de los que hablamos anteriormente. Por ejemplo, el estado repetible, puedes ver el historial, puedes ver cómo cambian las cosas con el tiempo, ¿verdad? Si terminas necesitando eso. Además, Redux, especialmente Redux, se puede cargar de forma diferida. Pero la mayoría de nuestros administradores de estado se pueden cargar de forma diferida. Digo Redux porque básicamente usamos React aquí. No tiene que ser así. Además, Redux probablemente sea uno de los administradores de estado más simples o más antiguos, algo así. Pero mucha gente lo conoce y puedes cargar de forma diferida módulos en un administrador de estado. Eso es bueno porque quieres cargar cosas cuando sean necesarias para esa característica. Sin embargo, es una mezcla. Crea ese acoplamiento. Lo hace muy, muy difícil trabajar con ese versionado. A medida que cargas múltiples versiones de aplicaciones de características, pueden anticipar diferentes estructuras de datos. Si esas estructuras de datos cambian entre versiones, mantener eso en Redux, en Redux solo tienes un nodo, un nodo de árbol de estado, ¿verdad? No puedes tener un árbol de estado con versiones, o podrías, pero tendrías que construirlo. Entonces crea ese acoplamiento, donde personalmente no soy un gran fanático, pero obviamente soluciona algunas cosas. Ahora, esto me lleva al enrutamiento. Verás, todas estas soluciones tienen pros y contras. No estoy tratando de decirte cuál es la mejor, aunque el enrutamiento es el más simple. Y hubo una pregunta sobre enrutamiento anteriormente. El enrutamiento es global, es holístico. Es una fuente única de verdad para toda la aplicación. Puedes pasar una ruta de estado, aún hay un componente de historial. Puedes conocer la ruta a ese punto final. Puedes compartir el punto en el estado con otras personas en redes sociales. Puedes hacer eso con el enrutamiento. Y de todo lo que mencioné, es el que tiene menos fricción o comunicación. Requiere, como mencioné anteriormente, historias porque es donde se ordena la información, debe ser singleton. No puedes tener dos versiones de esos porque entonces básicamente tendrías dos bibliotecas administrando el mismo historial y eso no podría terminar bien. Además, no puedes hacer todo con el enrutamiento, ¿verdad? No puedes enviar solicitudes para la ejecución de una función, como, oh, rastrea este evento. Podrías estar cambiando el estado, pero por eso el enrutamiento es incómodo. Puede ser incómodo hacer eso. De todas estas soluciones, creo que la que tiene menos fricción es el enrutamiento. Y la otra opción que me gusta es el patrón observable. Pero con una advertencia, y eso significa constantemente chicos, no se comuniquen y los equipos intenten no comunicarse demasiado, ¿verdad? También termino creando un puente para algunas de las brechas de memoria compartida, a veces termino creando una referencia muy, muy simple en memoria y haciendo eso una sola vez. Por lo general, lo llamo tienda, un almacenamiento compartido. Y ese almacenamiento compartido no es global, aún está limitado al módulo, pero nunca debe cambiar de versión porque siempre debe ser muy simple, nada debe cambiar, siempre es la misma referencia en memoria para JavaScript. Eso facilita mucho la solución de algunos de los problemas que surgen cuando tienes múltiples versiones de bibliotecas, ¿verdad? Echando un vistazo, bien, hasta ahora no hay preguntas. Gracias por todos los excelentes comentarios en esta grabación. Así que voy a seguir adelante, nos estamos pasando un poco de tiempo.

Si puedes quedarte, es fantástico. Si tienes que irte, está totalmente bien. Mencioné esto antes, así que no voy a dedicar mucho tiempo a esto. Al igual que en el sistema de diseño, tenemos átomos y moléculas, el organismo, las plantillas y las páginas. Los átomos son como un botón y la molécula es un componente que contiene múltiples átomos, eso creo que es bueno para los sistemas de diseño. Ahí es donde decimos qué tan granulares deben ser las cosas para los microframes. El organismo y las plantillas están en el diseño atómico. El organismo y las plantillas son... en mi experiencia, son el camino a seguir. Algo que no sea demasiado simple y que tenga cierta complejidad y valor empresarial. Es muy importante tener valor empresarial. Y esa es una buena separación para saber cuándo usar microframes. Este es un diagrama arquitectónico muy simple y básico que muestra nuevamente aplicaciones híbridas, navegadores, escritorio, cómo pueden funcionar juntos en la nube, ¿verdad? Cuando implementas todo... Puedes implementar todo en la nube. Puedes tener un sistema de gestión de contenido que básicamente funciona con estas características, permite a los autores de contenido crear características en la página. Y cada característica tiene su propio ciclo de vida. Tiene una integración continua, por lo que la integración continua del repositorio de GitHub, y la implementación, tiene vida propia. Lo importante que mencioné, voy a hablar un poco sobre las aplicaciones híbridas. Las aplicaciones híbridas pueden funcionar increíblemente bien. Siempre y cuando sea JavaScript. Tiene que ser un lenguaje interpretado según las pautas del código de la aplicación. Además, lo que puedes hacer, puedes hacer cosas increíbles como una actualización en caliente, cuando digo en caliente, eso fue negativo, pero conoces las pautas de la App Store. Puedes actualizar en caliente el código interpretado como JavaScript siempre y cuando sea un parche, no cambie la funcionalidad. Entonces, ¿qué obtienes de esto? Obtienes la capacidad de lanzar una aplicación móvil, una aplicación móvil híbrida, y cuando la lanzas, tienes que incluir todo en ella, ¿verdad? No puedes incluir solo el núcleo, tienes que incluir todo. Y hay estrategias que funcionan bien para la inclusión. No tienes que reconstruir toda la aplicación, puedes crear manifiestos y publicarlos en una CDN. Hay mucho más sobre MicroFriends. Pero lo genial de esto, el valor detrás de esto es que tus usuarios pueden trabajar con la aplicación, y a medida que trabajan, obtienen una actualización en caliente, su aplicación recibe una corrección, sin que tengan que actualizarla a través de la tienda de aplicaciones. Y siempre y cuando sea un parche, según, bueno, actualmente, al menos que yo sepa, según las pautas de la tienda de aplicaciones, eso está bien porque es un lenguaje interpretado. Voy a compartir algunos consejos contigo. Nuevamente, cuando trabajas con MicroFriends, dije, piensa de forma global pero actúa localmente. Así que concéntrate en el valor empresarial, pero esa perspectiva holística, en todo el sistema, siempre es útil tenerla. ¿Cómo interactúa mi aplicación de características con el sistema? ¿Qué es lo que está disponible en el conjunto completo, verdad? Hablé mucho de ser agnóstico. Sí, deberías ser agnóstico, eso es actuar localmente, pero esa pequeña cosa que está en tu hombro derecho mientras trabajas, pero pensar de manera holística ayuda mucho, especialmente si tu posición está dentro de la arquitectura de soluciones y cuando tienes que pensar en el panorama general, ¿verdad? No puedes desconectarte de eso. Siempre, siempre pregunta, cuando hago este incremento, ¿estoy creando acoplamiento? ¿Puedo hacer esto mejor para no crear acoplamiento? También hablé sobre implementar características en subcarpetas en lugar de en versus, y creo que eso es importante. Y cuando implementas en una CDN, lo que quieras implementar, cada nueva versión, te sugiero encarecidamente el versionado semántico. Hay varias bibliotecas que pueden ayudarte con eso. Implementa cada versión por separado, no sobrescribas. No es bueno sobrescribir porque nunca sabes qué versión están utilizando tus clientes, ¿verdad? Quieres agregar, quieres crear una nueva carpeta con nuevas versiones, y eso puede ser muy útil. También mencioné que cuando inyectas una característica, especialmente de forma dinámica en lugar de en sus límites para la recuperación automática y recuperar datos, estoy muy agradecido por esa pregunta. Voy a decirlo implícitamente, quiero decir, ve si puedes comunicarte solo a través de las rutas. Con eso me refiero principalmente, sí, ve si puedes comunicarte solo a través de eso. Lo más probable es que no puedas. Pero nuevamente, eso va en contra de tratar de no crear acoplamiento. Cuando trabajas de forma incremental, intenta pensar en la compatibilidad hacia atrás, porque como dije, nunca sabes quién usa una versión anterior. Si estás trabajando en el sistema más escalable de una organización global, entonces tal vez haya esos autores de contenido, alguien que no conoces que usa tu característica y no sabes qué versiones están utilizando. Y si hay una colisión que no es compatible hacia atrás, tal vez se rompa. Por lo tanto, pensar en la compatibilidad hacia atrás es útil. Y pensar en el versionado semántico también es útil. Así sabes cuándo usar mayor y menor eso puede ayudar a crear orden en este caos. Por lo general, para los estáticos, no necesitamos encabezados de curso, obviamente, pero en este caso, sugiero eso. La razón es, especialmente si alojas características en su propio subdominio o algo así. Cuando cargas JavaScript desde un subdominio diferente, eso va a funcionar, se va a cargar. Pero el JavaScript entre dominios crea una respuesta opaca. Eso significa que funcionará para una respuesta segura. El navegador va a intentar ocultar internamente los encabezados y ocultar parte del contenido por seguridad. Y tu caché se va a llenar. Entonces, en teoría, podrías tener tal vez 400 kilobytes de caché, pero terminas teniendo 400 megabytes de caché. Si bien no es cierto que uses 400 megabytes de JavaScript con respuestas opacas, aún superas los límites de caché o los límites de almacenamiento de archivos y tus navegadores pueden bloquearse, tu aplicación puede terminar sin estar en caché y, por lo tanto, cargar más lento. Entonces, si solo usas permitir curso y luego permitir asterisco, eso es suficientemente seguro para los estáticos. Permitirás que los navegadores carguen ese recurso de una manera no opaca. Los trabajadores de servicio podrán trabajar con él sin problemas y la caché funcionará.

Muy bien, Preguntas frecuentes, solo mencionaré lo que la gente suele preguntar, pero creo que ya mencioné algunas de estas cosas. ¿Puedo mezclar y combinar frameworks de JavaScript? Ya hablamos de eso. Técnicamente puedes, pero trata de no hacerlo. Si tienes una organización estricta, también mencioné eso, si es una organización estricta que solo quiere prescribir todo, ¿verdad? A veces es doloroso trabajar en esa organización porque quieres adivinar, quieres aprender cosas nuevas, quieres experimentar, quieres poder cometer errores, quieres tal vez intentar modernizar, pero no es posible. Está bien, ¿verdad? Está bien, también puedes trabajar con eso. ¿Debo usar monorepo? También mencioné eso. Por favor, probablemente no. Trata de no hacerlo. Los monorepos son buenos para las bibliotecas, pero para los microfrontends, para las aplicaciones de características, trata de separarlos en repositorios dedicados.

Ahora, la siguiente diapositiva es una parte de la presentación que he utilizado con personas de negocios porque no hablan el lenguaje de ingeniería. Es este segmento, y pensé que sería genial si ustedes quisieran usar parte de esta información para compartirla con sus jefes o clientes, para que si realmente quieren trabajar con microfrontends y que les paguen por ello, ¿por qué no? Una de las cosas que las organizaciones tienen es que los microfrontends realmente promueven la agilidad, cuando digo organización, me refiero a la empresa en general, implementaciones ágiles. Las curvas de aprendizaje son muy rápidas porque básicamente no necesitas aprender sobre toda la aplicación. Aprendes sobre tu unidad de negocio, aprendes sobre tu navegación o aprendes sobre tu autenticación, gestión de usuarios, solo aprendes sobre eso. Y si haces lo que hace la generación de micro módulos, si dices que cumple con los estándares, es increíblemente rápido integrarse a un equipo, salir de él y pasar a otro equipo. Los equipos se comunican de manera mucho más eficiente porque sabemos qué equipo es responsable de qué. Y puedes crear un canal de comunicación basado en equipos y decir, equipo, saben, Burger King. Tengo un problema con esto. Ustedes deciden quién me ayudará. Pero sé que esto está en su dominio y esa comunicación funciona increíblemente bien porque facilitas esa comunicación, en realidad obtienes más comunicación y eso significa que obtienes más retroalimentación. Y para la agilidad, realmente quieres retroalimentación para mejorar. Entonces, los microfrontends son un cambio organizacional y promueven la agilidad. Como dije, los microfrontends pueden ser pequeños o grandes según lo que funcione mejor para tu equipo. Como dije, no te vayas a lo demasiado pequeño, creo que es un buen consejo. Pero ajústalo a tu empresa. Por lo general, cuando comienzas, quieres tener personas como gerente de producto, diseñador, arquitectos, tal vez ingenieros de front-end, quieres hablar con ellos, solo quieres ver, oye, ¿cómo podemos decidir qué es la característica? Por lo general, llegarás al mismo punto. Y a veces quieres reiterar algunas de las ideas, pero llegas al mismo punto. Creas esa granularidad que funciona mejor para tu empresa. Entonces, lo que eso significa es que cuando tu empresa quiere lanzar un incremento, lanza solo esa pequeña parte, no toda la aplicación. Y simplemente funciona. ¿Y sabes para qué también es buena la granularidad? Las pruebas A B. Cuando tienes una aplicación granular, puedes ver lo increíblemente fácil o incluso poderoso que es crear pruebas A B para decir, oh, para este subconjunto, para un cierto subconjunto de usuarios, quiero usar la versión uno de mi característica y la versión dos para otros, pero tal vez quiero usar, quiero decir, beta cerrada o beta optativa, o quiero permitir que las personas opten por nuevas características. Esto es increíblemente importante para las organizaciones porque quieren poder no arruinar la experiencia del cliente. No quieren crear, por ejemplo, un diseño completamente nuevo demasiado rápido porque las personas tal vez se acostumbraron al antiguo. Las personas no piensan de la misma manera que nosotros, los usuarios no piensan de la misma manera que las personas que crean la aplicación. Entonces, cuando pensamos, oh, esto será mejor. Tal vez no lo acojan tan bien. Y si podemos aprender de eso, aprendemos de manera granular. Y si vemos que esto no funciona, entonces, como es granular, podemos reemplazarlo. Dices, oh, esta nueva ventana de inicio de sesión confunde a la gente. Oh, vamos a reemplazarla de inmediato. Vamos a arreglarlo de inmediato. Vamos a restaurar hasta que encontremos una nueva versión, una nueva forma de hacerlo. Nuevamente, si tu organización ha pasado alguna vez por una migración importante, sabrá que es doloroso. Es increíblemente costoso. Cuando creamos una infraestructura de microfrontends con una arquitectura, realmente es a prueba de futuro. Se vuelve mucho más fácil para una aplicación así migrar en el futuro. Es más barato. El patrón está bien definido. Es casi una obviedad. Y no solo eso, porque las cosas son granulares. Bueno, una cosa que obtienes, y lo viste en el último ejemplo, es también la carga diferida. Quiero decir, lo obtienes por defecto. Y lo que eso significa es que las aplicaciones, o, perdón, los usuarios cargan solo el JavaScript necesario. Solo lo necesario para que la interfaz de usuario se pueda utilizar. No necesitan cargar JavaScript para características que no están presentes en la ventana de visualización en ese momento. Y eso es algo que obtienes de forma predeterminada. Entonces, las aplicaciones también son mucho más rápidas. En cuanto a las actualizaciones, estas pueden ser realmente grandes y hablé un poco de eso porque no solo puedes reiterar, no solo puedes aprender y mejorar, mucho más rápido que con los monolitos, puedes solucionar problemas mucho más rápido. Puedes implementar correcciones de errores, parches rápidamente. No tienes que reconstruir toda la aplicación. Solo reconstruyes una pequeña característica. La implementas y listo. Los microfrontends nos permiten ver información realmente interesante, bueno, quiero decir, un panel de control. Información sobre cuánto nos cuesta desarrollar características, cuánto nos cuesta ponerlas en producción, cuánto nos cuestan en ancho de banda y ciclos. Si usas código de respaldo, porque todo está contenido como una característica, ¿verdad? Es casi un espacio de nombres. Puedes extraer mucha información localizada y aprender sobre el rendimiento de cada característica. No solo de cada característica, sino también de cada versión. No es solo un seguimiento, porque sabemos que el seguimiento no funciona para todos. Las personas son buenas bloqueando rastreadores. Pero esto es en el lado del servidor, y puedes rastrear solicitudes, y obtienes nuevas formas poderosas de aprender qué tan exitosa es la organización con las características y sus incrementos. Lo cual es realmente increíble para aprender cómo mejorar. Ahora, todo el concepto es algo que me gusta llamar característica como servicio. Y hablamos de eso, donde podemos implementar características en una CDN y luego inyectarlas en tiempo de ejecución. Entonces, el tiempo de ejecución, el tiempo de ejecución de Java es muy pequeño, lo que produce Webpack. Y realmente puedes volverte loco con un enjambre de características e inyectarlas según sea necesario. Básicamente, según se renderizan en la pantalla, se inyectan. Además, son muy buenos para saber si ya han sido inyectados, para poder reutilizar instancias existentes. Oh, la caché es increíble. Es muy oportuno almacenar en caché estas características e incluso precargar características de antemano. Tienes toda esta información que puedes utilizar para obtener beneficios de rendimiento. Y estamos utilizando Webpack. Webpack 5 es el estándar de la industria. No es el único bundler que tiene microfrontends. La implementación de Webpack es realmente sólida. Está probada. Para ser honesto, es el que más uso. Estoy muy familiarizado con él. Estoy familiarizado con Webpack tal como es. Pero permite grandes eficiencias para los desarrolladores. Esto se debe a que se enfocan en cosas en las que son buenos.

Los MicroFrontends ofrecen reutilización automática de código y la capacidad de compartir bibliotecas. Sin embargo, se pierden las capacidades de tree-shaking al usar bibliotecas compartidas. Esto se debe a que no se sabe qué parte de esa biblioteca se utilizará en la aplicación. La biblioteca completa se empaqueta cuando se utilizan bibliotecas compartidas, no solo la parte que se utiliza en esa característica. Esto se debe a que es compartida y no se sabe qué se va a utilizar. Aun así, la reutilización automática de código es excelente, ya que no es necesario empaquetar dos versiones de React o dos versiones de funciones de Dave. Es automático, se nos proporciona de forma predeterminada. Además, se mencionaron todas esas hermosas palabras clave que se pueden compartir. No es algo nuevo, ya que ha estado disponible desde el 10 de octubre de 2020, cuando se lanzó la versión de producción. Pero ya existía antes de eso. Personalmente, he implementado la Federación de MicroMódulos en no todas, pero la mayoría de estas empresas, más de la mitad de ellas. Y es algo que la gente utiliza. Han tenido éxito. Son grandes organizaciones. Son capaces de ejecutar sistemas enormes a nivel global, operados por cientos, miles de personas. Personas que crean aplicaciones de características, que diseñan aplicaciones de características. Personas que las utilizan para crear contenido. Personas que analizan. Personas que son empresarios. Realmente, como dije, no estamos probando la capacidad. Estamos en el punto en el que sabemos que esto funciona. Pero depende de nosotros ver si esto es para nosotros. Hoy, quería decirles que hay partes buenas de los MicroFrontends. También hay cosas de las que debes tener cuidado, ¿verdad? No debes dar todo por sentado. Leerás muchas cosas buenas sobre los MicroFrontends y cosas como que puedes usar cualquier biblioteca. Teóricamente, eso es cierto, pero en la práctica, debes tener cuidado para no dispararte en el pie. Ese es mi punto. Quería mostrarte lo bueno y lo feo. No quiero asustarte. Quiero decirte que está bien. Deberías probarlo. Deberías probarlo en producción. No puedo decirte exactamente cuál es el umbral de tamaño. Pero para aplicaciones pequeñas, puede ser excesivo. Pruébalo en un prototipo. Creo que los MicroFrontends son fantásticos para aplicaciones altamente escalables donde la parte frontal se escala técnicamente. Donde los equipos necesitan escalar. Cuando tienes un gran número de equipos que se crean o se deshacen, donde las personas se unen a los equipos y se van. Por lo general, son organizaciones más grandes. Funciona de manera fantástica para ellos. Y si tienes acceso a eso, ya sabes, siempre puedes comunicarte conmigo. Siempre puedes comunicarte y decir, oye, ¿qué sugieres, cómo debería hacer esto? Me encantaría ayudar. Nuevamente, si tienes una aplicación pequeña, eso es más como, ya sabes, déjame probar algo genial, puedes hacerlo. Pero no quiero que crees algo que tendrás que mantener en el futuro. Casi la última diapositiva. ¿Alguna pregunta hasta ahora? Cristian? Sí, escribí, escribí en, cómo se llama, Discord. ¿Podrías explicar un poco más sobre las carpetas de versiones? Déjame ver qué estoy compartiendo. Estoy compartiendo esta pantalla. Déjame ver si puedo. Sí, básicamente, se trata de la organización del código o de las rutas, que deben contener algo como V1, V2 o tal vez ambos. Es la organización del código implementado. Y si recuerdas, en el código, teníamos esa dirección de origen. Y dijimos, un héroe en un HTTPS, y blah, blah, blah, 8081, barra diagonal héroe digest, ¿verdad? Lo que haría ahora, haría dominio barra diagonal héroe digest. Básicamente, no usaría, no tendría que compartir la pantalla. En la configuración de Webpack, verás, creo que es library. La propiedad donde dice nombre de la biblioteca. Entonces siempre puede ser el mismo archivo, remoto. Me gusta usar remote.js. Para mí, es como index.js para HTML. Lo siento, index.html para HTML. Remote.js es ese tipo de archivo meta. Pero no haces dominio.com/barra diagonal remoto.js. Harías dominio.com/barra diagonal v1.2.3. v1.2.3. Cada vez que implementes la aplicación, incrementas. No incrementas, pero creas una carpeta para esa versión. No puedes tener dos implementaciones de la misma versión. Ese es mi punto. Te aseguras de que esa versión siempre esté disponible. Sí, está bien. Incluso para las personas que utilizan versiones desactualizadas de la aplicación. Esto no es algo que estará en la documentación de los MicroFrontends o la Federación de Módulos. Esto proviene de la experiencia, ¿verdad? Y funcionó muy bien. Sé que puedes decir, oh, entonces cada vez que hago eso, necesito cambiar mi URL. Así que tengo que preocuparme por estas URL. Pero también puedes ayudar con eso. Algunas organizaciones siempre van a realizar un seguimiento de los números de versión y siempre van a, a través de su proceso de control de calidad y demás, van a nominar la versión de producción actual. Entonces van a encontrar una forma a través de algún tipo de infraestructura donde puedas decir, oh, esta es la versión actual. Pero puedes hacer algo inteligente. Puedes crear, por ejemplo, si estás usando Lambda. Entonces, si usas la función Lambda OnEdge, van a decir, si escribo uno punto x, muéstrame la última versión en el rango uno. O si escribo barra diagonal última, muéstrame la última. O barra diagonal siguiente, muéstrame la última versión canary. Quiero decir, puedes jugar con eso.

Puedes crear analizadores como ese en el enrutamiento. Tiene sentido, tiene sentido, gracias. Gracias por tu pregunta. Déjame ver. Déjame ver, voy a revisar esto, si tienes otras preguntas, interrúmpeme.

¿Cómo puedo revertir una versión con un error cuando estoy usando la federación de módulos? Así que es la infraestructura que construyes alrededor de la federación de módulos. Y realmente hay varias formas de hacer esto. En este ejemplo, dije que puedes crear una herramienta en el backend que sepa cuando usas la palabra clave 'latest', te da la última versión. Entonces puedes decir, ok, dame la última versión y dale esta última versión, y tu frontend reconoce un error y incluso puedes pasar una excepción para ver, oh, este es un error con la característica, y luego puedes decir, ok, dame la, puedes programar la nube para darte la última versión conocida buena, o simplemente puedes trabajar en tu propia lógica en el frontend, es solo cómo despliegas, es cómo despliegas esa lógica empresarial de tu despliegue que te ayudará a entender cómo puedes cargar la versión anterior, ¿verdad? La última versión conocida buena. Ya sea que la rastrees, ya sea que adivines con la versión antigua y la invalides, tal vez la invalides, si informas, puedes decir, oh, si mi, digamos que New Relic informa múltiples problemas con una versión, voy a invalidar automáticamente esa versión. Y en tu infraestructura, lo que sea que signifique la invalidación, ya sea eliminar la carpeta, ya sea marcarla en RISC-E, lo que sea que hagas, haces eso y luego los usuarios cargan las versiones antiguas. En la AutoReparación, simplemente implementas eso y dices con ese viaje adicional. Así que tu primer viaje fue a tu Hero.js y luego sabes, oh hay un error. Pero luego tienes que crear otro viaje, digamos que no funcionó. No funcionó.js, ¿verdad? Y luego tu backend te devuelve la versión anterior, ¿verdad? Esa es la esencia de ello. Subcarpeta de versión, creo que acabamos de hablar de eso.

Gracias a todos por todo el apoyo y los comentarios increíbles. Antes de irnos, déjame ver. Así que trabajo en una empresa que me permitió escribir algo así en una diapositiva. Fui muy sarcástico cuando escribí esto, pero no de manera negativa. Solo estaba jugando. De todos modos, si ustedes están eventualmente buscando mejorar su carrera, no duden en comunicarse en Moduscrew.com. La empresa siempre está contratando, está creciendo como loca. Trabajamos con muchas tecnologías, pero en términos de federación de módulos, sé de al menos tres grandes empresas que utilizan la federación de módulos con Modus. Así que si tienen ganas de probarlo, no duden en comunicarse. Sí, probablemente me despidan cuando alguien vea la grabación de este mensaje, pero realmente necesitaba hacerlo. Ok, chicos, muchas gracias. Ha sido un placer estar con ustedes hoy. Gracias por unirse a JS Nation y a esta masterclass. Significó mucho para mí.