Escalando con Remix y Micro Frontends

¡Hey! Hola a todos. Y bienvenidos a esta charla, Escalando con Remix y Microfontains, en la que hablaremos sobre cómo usar Microfontains en Remix. Un poco sobre mí. Mi nombre es Soy un ingeniero de software senior en Tractable, que es una empresa genial que hace AI y aprendizaje de máquinas para seguros. Así que tomamos tecnología genial en un mercado bastante aburrido, e intentamos hacerlo más moderno. Antes de eso, era un ingeniero de software principal en Kazoo, y en esa empresa, lideré el esfuerzo de microfontain. Así que voy a hablar principalmente sobre mi trabajo allí.

Entonces, probablemente te estés preguntando, ¿qué es un kazoo? Probablemente pensé en eso. Ese no es el tipo de kazoo del que vamos a hablar. Voy a hablar de este kazoo. Kazoo es una mejor manera de comprar un coche usado. Es básicamente, para las personas en los EE. UU., es un clon de Carvanha, pero en el Reino Unido. Y lo que hace es, básicamente compran coches usados y luego los venden en línea. Lo entregan en tu puerta, y tienes siete días para probarlo. Si no te gusta, simplemente devuelves el coche, sin problema, sin preguntas. Así que es solo tu e-commerce tradicional. Como, para las personas que construyen como nosotros, miras esto, dices, oh, es un sitio web de e-commerce. Sí, es un sitio web de e-commerce. Excepto cada

Entonces, desde una perspectiva de implementación, básicamente tienes el dominio Kazuko UK y diferentes aplicaciones separadas que se despliegan de forma independiente y todas poseen un conjunto de páginas en el dominio. Entonces, si miras eso desde una perspectiva de remix, eso sería básicamente múltiples aplicaciones de remix desplegadas por separado, como de forma independiente por equipos, pero todas apuntando al mismo dominio, si eso tiene sentido. En Kazuko, no usaron remix, usaron Next porque se construyó antes, pero potencialmente podrían migrar a remix.

Entonces, ese enfoque funciona muy bien. Y se llama, como, segmentación vertical en la arquitectura de microfrontends, como este tipo de cada equipo en un conjunto de páginas. Pero vimos que a veces no era lo suficientemente granular. Así que imaginemos un escenario que realmente tuvimos en Kazuko, que es un equipo de financiamiento al consumidor, que proporciona esta cosa de solicitud de préstamo es como, ¿sabes qué? Para impulsar la conversión, porque queremos vender más préstamos, necesitamos mostrar un calculador de financiamiento en el detalle de un vehículo dado, la página de detalles del vehículo. O por ejemplo, cuando haces un pedido y quieres rescindir tu entrega en mi cuenta, querrías ver algún tipo de cosa que te permita seleccionar los espacios disponibles. Y hay un equipo que posee toda la logística de mover coches. Y este es el que sabe sobre los espacios disponibles y cómo debería ser la UI y la UX para que las personas puedan reservar espacios. Así que quieren desplegar su cosa en mi cuenta. Finalmente, eso es algo que casi todo el mundo tiene, un encabezado y un pie de página, que necesitan ser consistentes en todo el sitio web. Entonces, si estás en una empresa que despliega algunas aplicaciones en producción y tienes una marca consistente, como si haces esto tipo de segmentación vertical ya, entonces probablemente ya tienes ese problema. Como probablemente tienes un encabezado y pie de página en los que todo el mundo necesita depender. Y ese problema de proporcionar un segmento de la página como este, un segmento horizontal de la página se llama segmentación horizontal en el mundo de los microfrontends. Sí. Entonces, lo primero que viene a la mente y como ingeniero de front-end, estás como, oh sí, eso puede ser un paquete de NPM, ¿verdad? Como voy a publicar un paquete en NPM, como en nuestro repositorio privado interno o algo que contiene un componente de React, que es un encabezado y un pie de página y todo el mundo simplemente instalará eso en la aplicación y lo renderizará hecho, ¿verdad? Sí, pero acabamos de introducir una dependencia en tiempo de compilación entre dos equipos al hacer esto, lo que significa que cualquier cambio en el encabezado por parte del equipo que posee el encabezado necesita actualización y re-despliegue de cada aplicación que depende del encabezado. Así que eso significa que ahora nuestro equipo que gestiona ese contenido básicamente necesita, cada vez que hacen un cambio, ir a ver a cada equipo y decir, por favor, ¿puedes actualizar y desplegar tu aplicación de nuevo? Lo cual es realmente doloroso y como que obstaculiza la capacidad del equipo para desplegar rápido. Así que queremos que ese patrón de paquete de NPM funcione bastante bien. Pero querríamos despliegues independientes. Introduciendo tiny frontend. Entonces, para resolver ese problema exacto en KSU, construí una biblioteca que se llama tiny frontend y básicamente apunta a resolver ese tipo específico de problema de microfrontend. ¿Qué es el tiny frontend? Es un paquete de NPM que busca

La opción manual para cambios destructivos significa que cuando un equipo, en realidad, que en el encabezado, en realidad necesita hacer algo nuevo para hacer ese trabajo. Por ejemplo, acabamos de traducir, como, hicimos nuestro sitio web internacionalizado y ahora el componente necesita saber qué idioma necesita mostrar. De lo contrario, no puede hacer el trabajo. Bueno, en ese caso, necesitaremos comunicarnos con el equipo que eligió ese componente para ser como, en realidad, no, por favor, necesitas proporcionar el idioma como parte del contrato a ese componente para que pueda hacer mi trabajo. Y en ese caso, haces básicamente una nueva versión del paquete y pides a los equipos que actualicen manualmente y cambien la base de código porque en realidad necesitan cambiar algo en la base de código para que el componente pueda funcionar.

¿Cómo se ve la arquitectura? Entonces, tenemos este increíble diagrama que, como, todo el mundo está como, oh, Dios mío, ¿qué está pasando aquí? Hay tantas cajas rosadas. Vamos a repasarlas una por una. La primera, el host. Entonces, lo que va a mostrar ese micrófono. Entonces, una aplicación Remix en este caso. La segunda es un pequeño frontend. Es una pieza de frontend, un encabezado, un pie de página, algún tipo de componente que va a ser consumido por el host. Entonces, se muestra dentro de la aplicación host y se compone de dos carpetas, una carpeta de aplicación que contiene la fuente real de tu componente de React y un contrato, que es un paquete de NPM que vas a publicar para las personas que quieran consumir eso en tiempo de ejecución para poder hacerlo. Y finalmente, porque estamos hablando de desplegar esos paquetes de este pequeño frontend porque necesitamos poder cambiarlos, porque no están en el paquete de NPM, pueden cambiar en algún lugar, necesitan estar en algún lugar para empujar esos paquetes. Y en este caso, es una pequeña API construida en Cloudflare y desplegada en Cloudflare como un trabajador de Cloudflare.

Genial. Entonces, nuestro host de ejemplo, en este caso, Remix, va a instalar el paquete de NPM, que proporciona un método que es asíncrono, y cuando llamas a ese método, te devuelve un componente de React que puedes usar en tu aplicación. Cuando llamas a ese método, ¿qué hace? Bueno, usa una pequeña biblioteca de cliente para llamar a una API para obtener la última versión del paquete. Entonces, toda la complejidad de, como, ¿cómo obtengo un componente de React en tiempo de ejecución de un paquete que está desplegado en algún lugar y todo eso, todo eso se abstrae en la biblioteca. Entonces, cuando construyes un nuevo pequeño frontend, no necesitas reinventar la rueda todo el tiempo y copiar y pegar mucho código. Puedes simplemente tener básicamente todo está abstraído en una biblioteca que usas. Entonces, cuando el equipo que tiene el pequeño frontend, por ejemplo, el equipo del encabezado, tiene una nueva versión del encabezado, simplemente, como, empujan al repositorio, tendrán algo así como, por ejemplo, una acción de GitHub que va a empaquetar el nuevo componente, y luego desplegar ese paquete a esta API de Cloudflare. Y básicamente se actualizará

Así que podemos ver que esta base de code tiene dos cosas, como vimos. El contrato, que es este paquete de NPM que la aplicación remix instala. Y la aplicación, que es una fuente para ese componente. Genial. Puedes ver que puedo presionar. Y hay comunicación entre los dos. Esto es porque esto es solo un componente regular de React en tiempo de ejecución. Así que la comunicación es simplemente literalmente la aplicación remix puede pasar callbacks. Y haces la comunicación de la forma en que normalmente haces la comunicación en una aplicación de React. Así que algunos marcos de Microflaren framework tienen buses y cosas así. Pero aquí, porque usamos el framework como el pegamento, todo lo que tenemos que hacer es pasar callbacks, por ejemplo, si quieres. Otra cosa agradable que podemos ver es si desactivo JavaScript y refresco la página, puedes ver que todavía puedo ver ese componente. Así que TinyFrontend funciona con el renderizado del lado del servidor. Así que la aplicación remix realmente carga el componente, como la última versión del componente, desde la red en tiempo de ejecución en el servidor y utiliza ese componente para renderizar la página en el servidor. Luego también lo carga en el cliente y lo utiliza para la rehidratación. Así que si vuelvo a habilitar JavaScript y recargo, las cosas siguen funcionando, y para demostrar que no estoy mintiendo sobre el cliente, aquí hay un componente que se carga en el cliente. Podemos ver que se carga desde esta URL de Cloudflare porque es una API de Cloudflare que sirve este paquete, y si lo abro, puedes ver que tiene este texto, como, hola y los enlaces, y yo estaba desplegado y todo.

Genial. Entonces, ahora, veamos cómo cambia realmente. Entonces, si vamos a la fuente de esta aplicación y vamos a nuestro componente, podemos cambiar, por ejemplo, el texto aquí, digamos, Hola Remix Europa. Y cambiemos también el color, así que si vamos aquí y cambiamos esto a ser Rebecca Purple, entonces podremos hacer un commit de esto. Entonces, he hecho un commit de este cambio y lo estoy empujando. Sin embargo, ahora, no estoy haciendo un cambio en la aplicación Remix, solo estoy cambiando ese componente solamente. Entonces, acabo de hacer push en el repositorio que contiene la fuente para este componente aquí, ¿verdad? Por lo tanto, la aplicación Remix no se vuelve a desplegar, nada cambia allí, sigue siendo la misma aplicación. Si vamos a las acciones, podemos ver que hay una acción que comenzó en GitHub Action. Actualmente está ejecutando el CI, por lo que está instalando las dependencias para construir el último paquete de este componente. Se está desplegando y ahora se ha desplegado con éxito. Entonces ahora si vamos aquí y actualizamos, vemos que ahora es el nuevo componente. Así que presiona remix Europa y la botella ahora es púrpura y no tuvimos que tocar nuestra aplicación remix. Bastante genial, ¿verdad?

Así que querríamos algún tipo de anfitrión remix en funcionamiento que pudiera guardar páginas tanto de un remoto A o remoto B y manejar todo para nosotros. Así que construí una prueba de concepto muy pequeña, muy básica que muestra que es bastante fácil lograr eso en remix. Principalmente necesitas cambiar algunas cosas en la fuente de remix. Aunque, si te sientes realmente aventurero, puedes usar mi demostración para intentar hacerlo tú mismo. Pero si esperas, he oído que es posible que... como la federación de módulos Webpack, a remix y te permita hacer eso de una manera más soportada por el framework. Bueno. Tiempo de demostración para esa cosa. Genial. Así que aquí está mi aplicación Playground de federación remix y tenemos dos aplicaciones. Tenemos un anfitrión y un remoto. El anfitrión es el que está funcionando actualmente y puedes ver en su aplicación en sus raíces, sólo tiene un índice con un enlace a una página slash remota que no existe en esta base de code. También tenemos otra base de code llamada remix remota y esa contiene una página remota que está allí. ¿Qué pasa si hago clic en este enlace? Hey, navegé de una aplicación a la otra. Ahora, lo realmente genial es que esto es en realidad un regular, como, no hay recarga de página, nada, es del lado del cliente, esta es una navegación remix regular. Así que se comporta como si la página remota fuera parte de la aplicación anfitriona remix. Aún mejor que esto, tenemos cosas como, por ejemplo, la recarga en vivo funciona. Así que si cambio el remix remoto, en realidad se recarga dentro de la aplicación anfitriona. Y tenemos cosas, todo lo que esperas de remix, como la función de acción también funciona. Así que, por ejemplo, envío este formulario. En realidad va a llamar a esta acción, y esa función en realidad va a funcionar dentro de la aplicación anfitriona. No voy a entrar en detalles de cómo funciona eso porque no tengo tiempo. Pero si buscas en la discussion en el GitHub de remix, podrías encontrar cómo funciona esto. Y eso fue todo. Ahora vamos a cambiar a preguntas y respuestas. Gracias a todos por escuchar mi charla. Asegúrate de seguirme en Twitter

Sí. Eso es un buen punto. Aunque creo que generalmente abogo por no usar micro-frontends para mezclar frameworks, a menos que estés haciendo algún tipo de migración donde estás decidiendo explícitamente migrar de React a Zvelt, o dices que este no es el lenguaje que queremos usar más. Y mientras tanto, mientras estamos migrando, vamos a tener ambos al mismo tiempo. La razón es, creo que es como permitir múltiples frameworks permite básicamente la libertad del desarrollador pero viene con un costo de performance para tus usuarios, porque entonces tienen que hacer múltiples frameworks en el cliente para hacer que todo funcione junto. Así que creo que generalmente estoy como, trata de usar un framework, para que puedas hacer el costo del framework sólo una vez, ¿tiene sentido? Creo que sí tiene sentido. La razón por la que lo mencioné es porque cuando estaba en Grainger, teníamos como, había React, había jQuery, componentes de Hybris, había componentes de Svelte. Así que teníamos como todo trabajando juntos y las cosas habían sido hechas por empresas contratistas u otras cosas, otras empresas. Y luego nuestro equipo estaba trabajando en la pieza de Svelte y luego terminaron cambiando a React. Así estábamos trabajando con todos estos dentro de la misma aplicación y eso podría ser como un futuro. Así me preguntaba cuáles eran tus pensamientos al respecto, pero estoy de acuerdo, si tienes la opción de quedarte con un solo framework, es mucho menos sobrecarga para tu empresa. Entonces, ¿sugieres que la gente use un micro front-end en su empresa? Así que creo que Ruben Cazas, que es una persona que también habla mucho sobre micro front-end, también tiene algunas charlas sobre si debes usar micro front-end en tu empresa? Y creo que puedo estar de acuerdo con su opinión, que es usar micro front-end si resuelve un problema para tu empresa. Así que si tienes sólo unos pocos equipos y puedes compartir un monorepo y todos pueden contribuir y no tienes puntos de dolor allí, sólo haz un monorepo, haz esto y está bien. Si empiezas a sentir el dolor de como, necesitamos ser capaces de desplegar

Es como cualquier otra pregunta de desarrollador. Depende. Sí, exactamente. Desarrolladores senior. Correcto. Bueno, tenemos una pregunta más para ti. Esto es un poco volviendo a la pregunta de Baymax anteriormente con la federación de módulos de webpack. ¿Está tiny front-end utilizando la federación de módulos de webpack? Buena pregunta. Así que no, no lo está. Podría, como la implementación subyacente podría usar la federación de módulos de webpack. Cuando lo construí, decidí no hacerlo. La razón principal es que no está utilizando webpack para agrupar, en realidad está utilizando creo que ESBuild. Quiero decir que está utilizando VIT. Y la razón principal es que en tiny front-end especificas cada dependencia que estás compartiendo como en tus dependencias de aspia. Y básicamente lo que hace es solo un poco de pegamento para exponer esas en el contexto global y luego conectarlas para ti. Y la federación de módulos de webpack puede hacer muchas cosas por ti, puede hacer como resolución de versión dinámica y todas esas cosas. Y eso no era realmente necesario para tiny front-end porque tú no puedes tener solo esta relación uno a uno entre el host y el paquete que entra. Por eso no lo elegí, es un poco más ligero. Pero para ser justos, sabes, como si por ejemplo la federación de módulos de webpack se convierte en un diagnóstico de paquete y como un estándar y todo el mundo empieza a usarlo, entonces sería bastante trivial cambiar los componentes internos de tiny front-end para usar eso en su lugar. Sí, eso es increíble, bueno, creo que eso es todo el tiempo que tenemos para hoy. Muchas gracias Adrian por unirte a nosotros para la sesión de preguntas y respuestas y gracias por la charla. Sí, gracias, gracias por invitarme, saludos.