1. Introducción a Remix y Microfontains
En esta charla, discutiremos cómo usar Microfontains en Remix. Tengo experiencia como ingeniero de software senior en Tractable y como ingeniero de software principal en Kazoo, donde lideré el esfuerzo de microfontain.
¡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í.
2. Introducción a Kazoo
Kazoo es una mejor manera de comprar un coche usado. Compran coches usados, los venden en línea y los entregan en tu puerta. Tienes siete días para probarlo y si no te gusta, puedes devolverlo. Es como un sitio web de comercio electrónico tradicional, pero con artículos de alto valor.
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
3. Front-end en Kazoo e Introducción a Tiny Frontend
Kazoo sigue un enfoque de diseño orientado al dominio, con cada segmento vertical propiedad de un equipo específico. Ejemplos de segmentos incluyen búsqueda y navegación, mi cuenta y financiamiento al consumidor. Kazoo despliega aplicaciones separadas de forma independiente, pero todas enraizadas en el mismo dominio. Encontraron problemas con el segmento granular e introdujeron el segmento horizontal. El desafío de proporcionar un segmento horizontal se llama segmento horizontal en el mundo de los microfrontends. Para resolver esto, el orador creó una biblioteca llamada tiny frontend, que es un paquete NPM que busca la última implementación desplegada en tiempo de ejecución.
¿Cada artículo cuesta como £10,000 o algo así, verdad? Genial. Entonces, ¿cómo se ve el front-end en Kazoo? Desde el principio, Kazoo ha estado siguiendo un enfoque de diseño orientado al dominio, lo que significa que cada segmento vertical del problema es propiedad de un equipo específico y ellos poseen toda la pila para ese problema específico. Así que poseen el front-end, el back-end, el despliegue, todo. Entonces, ¿cuáles son algunos ejemplos de segmentos, podrías preguntar? Por ejemplo, podrías tener búsqueda y navegación, que es cuando buscas un vehículo, ves el detalle de un vehículo, todas estas cosas. Tendrías mi cuenta que te permite ver tu información de cuenta y pedidos anteriores, o financiamiento al consumidor, que es la solicitud de préstamo en línea. Así que cuando compras el vehículo, puedes solicitar un préstamo. Y hay muchos forms que te preguntan muchas cosas realmente divertidas como dónde has vivido en los últimos tres años. Y eso es una aplicación separada, es un segmento del problema de vender un coche en línea.
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
4. Introducción a TinyFrontend
TinyFrontend es una implementación con opiniones de la arquitectura de microfrontend destinada a resolver el problema de segmentación. Sigue el principio de usar el marco como pegamento en tiempo de ejecución, esperando que el host tenga React. El host debería ser una aplicación remix vainilla o cualquier aplicación vainilla que use React. TinyFrontend tiene como objetivo ser fácil de consumir, como un paquete npm regular, y promueve la seguridad de tipo y la compatibilidad de las dependencias compartidas en tiempo de compilación.
su última implementación desplegada en tiempo de ejecución. Así que imagina un paquete NPM que insertas en tu proyecto pero no contiene la fuente real del componente React sino que busca la última en tiempo de ejecución. Es una implementación con opiniones de la arquitectura de microfrontend architecture y está destinada a resolver el problema de segmentación. No es la única forma verdadera de microfrontend como microfrontend es solo una architecture. Hay muchas soluciones diferentes por ahí que son diferentes compensaciones. Esta es solo una de ellas. No está destinada a resolver el problema de segmentación vertical. Entonces, por ejemplo, no le importa el enrutamiento o algo así. Está aquí solo para proporcionar el componente en tiempo de ejecución. OK, algunos principios guía que sigue tinyfrontend. Usa el framework como pegamento en tiempo de ejecución. Entonces, la idea es, por ejemplo, es posible que hayas oído hablar de web components o cosas así, y hay bastantes soluciones que te permiten usar frameworks cruzados como una aplicación Angular, consumir un componente React, o cosas así. Esto no es lo que tinyfrontend quiere hacer. Quiere decir simplemente genial, vas a desplegar un componente React, y tu host va a ser una aplicación React. Es como una biblioteca. Esperas que tu host tenga React. Podría ser Vue, podría ser algo más, pero es una suposición que estamos haciendo. ¿Por qué quieres hacer eso? Porque tener varios frameworks ejecutándose en la misma página no es bueno para el performance, por lo general tener un framework consistente para toda tu empresa hace una mejor user experience. Segundo principio, no necesitas nada especial para consumir un TinyFrontend. Una vez más, algunas implementaciones de Microfrontend te requerirán tener una gran aplicación host que sabe muchas cosas. Básicamente es más como un framework que una biblioteca, y TinyFrontend es más como una biblioteca. El host debería ser solo una aplicación remix vainilla, o una aplicación vainilla que usa React. No queremos que el host tenga nada complicado. Para ellos debería ser realmente fácil. Debería ser básicamente lo mismo que consumir un paquete npm regular. Tercero, ser seguro de tipo. Nos gusta la type safety. TypeScript es nuestro amigo. Si podemos proporcionar los tipos de nuestro componente al equipo que lo consume para que puedan asegurarse de que su code se ejecutará contra él en tiempo de ejecución, eso sería genial. Asegúrate de que las dependencias compartidas sean compatibles en tiempo de compilación. Porque estamos proporcionando ese componente al
5. Gestión de Dependencias y Visión General de la Arquitectura
La aplicación host puede tener diferentes versiones de React. La opción automática para cambios no destructivos es ideal, donde los componentes pueden actualizarse sin requerir ninguna acción por parte de los equipos que los utilizan. La opción manual para cambios destructivos implica comunicar la necesidad de cambios en la base de código y actualizar la versión del paquete. La arquitectura consta de una aplicación host, un microfrontend compuesto por componentes de frontend y un contrato, y una API de Cloudflare para desplegar y actualizar paquetes. La aplicación host instala el paquete NPM, que proporciona un método para obtener la última versión del paquete. La complejidad de obtener y usar los paquetes se abstrae en una biblioteca, facilitando el desarrollo y despliegue de nuevas versiones de los componentes de frontend.
otro equipo, nuestro componente podría estar usando una versión de React. La aplicación host podría tener una versión diferente de React. Querríamos alguna forma de verificar que esas dependencias son compatibles en el momento de la compilación. Luego, la opción automática para cambios no destructivos. Esta es la idea de, como, tengo un encabezado, no necesita ninguna información, es solo un componente de React y el tipo es solo, como, genial, es un encabezado, renderízalo, va a mostrar el encabezado. Cuando alguien cambia una copia dentro del encabezado, el color, lo que sea, el contrato de ese componente no cambia. Entonces el equipo que usa el encabezado no debería tener que hacer nada. Si refrescas la página, deberías ver el nuevo encabezado cuando se publique uno nuevo.
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á
6. Demo de TinyFrontend y Renderizado del lado del Servidor
Alguien, entonces, como un usuario, por ejemplo, ahora vendrá a nuestra aplicación Remix y refrescará la página. Debido a que el paquete ha cambiado, obtendremos el nuevo paquete y simplemente renderizaremos la aplicación con el nuevo componente. Bien. Así que aquí tenemos una pequeña aplicación de frontend. Esa pequeña aplicación de frontend es esta, como, caja aquí en rosa. Todo dentro de eso es un componente que se despliega de forma independiente. Y es esta base de código. Y todo lo demás es solo una aplicación regular de Remix. Otra cosa agradable que podemos ver es que 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. Entonces, 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. Así que puedes ver que esta es la fuente real de ese componente.
el estado allí para decir, este es ahora el nuevo paquete. Alguien entonces, como un usuario, por ejemplo, ahora vendrá a nuestra aplicación Remix y refrescará la página. Debido a que el paquete ha cambiado, obtendremos el nuevo paquete y simplemente renderizaremos la aplicación con el nuevo componente. Bien. Vale. Así que ahora vamos a ir a una pequeña demostración. Porque tiene mucho más sentido cuando lo ves por ti mismo. Genial. Así que aquí tenemos una pequeña aplicación frontend. Esa pequeña aplicación frontend es esta, como, caja aquí en rosa. Todo dentro de eso es un componente que se despliega de forma independiente. Y es esta base de code. Y todo lo demás es solo una aplicación regular de remix.
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.
7. Consumiendo el Componento en Remix
En el lado de Remix, consumimos el componente utilizando la función loadTinyFrontEndServer. Esta función es proporcionada por el paquete npm instalado en la aplicación remix y devuelve una promesa que contiene el componente. Almacenamos el componente en el contexto global, lo que nos permite renderizarlo en el servidor. El mismo proceso se sigue en el lado del cliente antes de rehidratar la aplicación remix.
Entonces puedes ver que esta es la fuente real de ese componente. Sí, ahora vamos al lado de Remix y veamos cómo consumimos ese componente. Entonces, en el lado de Remix, si vamos a nuestra página renderizada en el servidor que acabamos de ver, aquí está el texto y todo, podemos ver que obtenemos este componente y es solo un componente regular. También podemos verlo como un tipo. Entonces, por ejemplo, espera una propiedad name. Si lo eliminamos, se va a quejar y decir, necesitas proporcionar un name. ¿Y cómo lo obtenemos? Bueno, lo obtenemos ya sea del cliente o del servidor, dependiendo de si estamos en el cliente o en el servidor, y por ejemplo, en el servidor, ¿cómo se carga? Tenemos una función llamada loadTinyFrontEndServer que es proporcionada por ese paquete npm que instalamos en esta aplicación remix, y devuelve una promesa de básicamente algo que contiene nuestro componente. Y simplemente lo almacenamos en el contexto global. Eso significa que en el servidor, llamamos a esta función inicialmente, y una vez que esperamos esa función, sabemos que el componente existe en el servidor y que realmente podemos renderizar. En el cliente, hacemos lo mismo, pero llamamos al cliente uno, y hacemos eso antes de rehidratar la aplicación remix. Probablemente haya alguna optimización que podrías hacer alrededor de la página y todo, pero, sí.
8. Actualizando el Componente en Remix
Podemos cambiar el texto y el color del componente sin volver a desplegar la aplicación Remix. El componente se actualiza al realizar cambios en el repositorio, lo que desencadena la canalización de CI/CD y despliega el nuevo paquete. La aplicación Remix automáticamente obtiene la última versión del componente, resultando en la actualización de la interfaz de usuario.
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?
Remix y el Rebanado Vertical
Con Remix, podemos lograr el despliegue independiente de aplicaciones mientras mantenemos una aplicación Remix federada que funciona a través de límites. El orador demuestra un concepto de prueba y menciona la posibilidad de usar la federación de módulos Webpack para un enfoque más soportado por el marco. En la demostración, el orador muestra cómo la navegación entre aplicaciones, la recarga en vivo y las funciones de acción funcionan sin problemas dentro de la aplicación anfitriona Remix. El orador concluye la charla e invita a la audiencia a una sesión de preguntas y respuestas, animándolos a seguirlo en Twitter.
Bueno, eso es el rebanado horizontal. Pero, ¿qué pasa con el rebanado vertical, preguntas? Con remix, ¿podemos hacer algo al respecto? No sé si lo recordaste, pero teníamos esta aplicación remix muy independiente, ¿verdad? Y idealmente lo que querríamos, como uno de los problemas que tenemos con esto es cuando la gente cambia entre aplicaciones, en realidad tendrías que descargar React de nuevo, ¿verdad? Como cada aplicación enviará su propio React y remix y React Router y todas esas dependencias. Así que idealmente, queremos que la gente pueda, como los equipos puedan desplegar su propia aplicación de forma independiente pero en tiempo de ejecución es una aplicación remix federada que simplemente funciona a través de límites.
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
Resultados de Slido y Uso de Micro Front Ends
Discutimos los resultados de Slido sobre el uso de micro front ends. El 75% de las personas dijeron que no, mientras que el 25% dijo que sí. El orador enfatiza que no todos necesitan usar micro front ends y que depende de la empresa y sus puntos de dolor. Comparten su experiencia de trabajar en Netlify, donde no se utilizan micro front ends, y en Grainger, donde sí se utilizaban. La decisión de usar micro front ends depende de la arquitectura de la empresa.
en Baron André. Y sí, gracias a todos. Saludos. Primero, vamos a repasar los resultados de Slido que preguntamos al principio de tu charla. Así que vamos a ver los resultados para ¿estás usando micro front ends en tu empresa? Voy a cambiar a esa vista y ver cuáles son los resultados. Así que no, el 75% de las personas dijeron que no a eso. Eso es una locura. Y luego el 25% de las personas dijeron que sí. ¿Te sorprende eso? Supongo que depende de la empresa para la que trabajes, ¿verdad? Creo que no todo el mundo necesita usar micro front ends. Usa micro front end si realmente resuelve un punto de dolor en tu empresa. Así que está totalmente bien no usarlos. Así que supongo que depende de la audiencia y de dónde sean y dónde trabajen, supongo. Supongo que eso es muy cierto. Actualmente trabajo para Netlify. Y no usamos micro front ends. Pero trabajé para Grainger antes y sí los usábamos allí. Así que depende mucho de la empresa para la que estés trabajando
Función Favorita de Remix: Formulario y Mutaciones
La función favorita de Remix entre la audiencia y los oradores es Formulario y Mutaciones. Se elogia por su simplicidad y facilidad de uso, especialmente en comparación con otros marcos de trabajo como Next.js. La capacidad de cambiar datos usando un formulario y que funcione incluso sin JavaScript se considera una gran fortaleza del marco de trabajo Remix.
y cuál es su arquitectura. Así que eso tiene mucho sentido. Así que tenemos otra pregunta que hicimos a la audiencia al principio. Y también se la hemos estado haciendo a nuestros oradores todo el día. Así que nos gustaría saber, ¿cuál es tu característica favorita de Remix? Vale. Voy a ser súper original aquí y responder lo que casi todo el mundo hizo, que es Formulario y Mutaciones. ¡Yay! Vaya originalidad. Sí, por la mayoría de las razones, creo que la gente ha dicho, es realmente, como, creo que cuando usas Remix por primera vez, sabes, escribes el cargador, renderizas la página, ves los datos. Bueno, si has usado Competitor, no quiero decir la palabra, pero como Next.js u otros marcos de trabajo similares, estás como, no hay nada nuevo aquí. Y pero luego miras cómo cambio los datos? Y entonces estás como, oh, espera, esto es, como, mucho más fácil. Simplemente usa un formulario. Y luego apagas JavaScript. Y estás como, oh dios mío, funciona incluso en ese caso. Y hace tantas cosas bajo el capó por sí mismo. Lo cual es realmente, realmente agradable. Como, creo que definitivamente es mi característica favorita. Creo que es una de las grandes fortalezas del marco de trabajo. Estoy de acuerdo con eso también. Creo que especialmente si estás trabajando con formularios día tras día, y ves que eso necesita suceder en tu marco de trabajo, y luego no tienes eso disponible o es difícil de implementar, entonces Remix simplemente
Arquitectura de Remix y Micro Frontends
¿No reduce la arquitectura de Remix con enrutamiento basado en archivos la necesidad de micro frontends? Bueno, depende. En el caso de Kazoo, donde varios equipos están trabajando en el mismo código, usar un mono repositorio sería la única forma de lograr eso con una sola aplicación Remix. Sin embargo, un mono repositorio presenta desafíos en términos de despliegue y cola de PR. Por lo tanto, si quieres mantener un pequeño repositorio independiente para una parte de tu aplicación, los micro frontends aún pueden ser útiles con Remix.
lo hace muy fácil. Así que esa es una gran característica. Tenemos nuestra primera pregunta de la audiencia de Baymax, ¿no reduce la arquitectura de Remix con enrutamiento basado en archivos la necesidad de micro frontends? Bueno, diría que depende. Uno de los puntos de dolor, en el ejemplo que estaba dando, que era Kazoo, estamos hablando de un código en el que muchos ingenieros están trabajando al mismo tiempo. Kazoo es probablemente, no quiero decir, como en los sitios web públicos, probablemente como al menos diez equipos de unas siete personas, ocho personas. Así que eso es mucha gente trabajando en el mismo código. La única forma de hacer eso con una sola aplicación de Remix sería un mono repositorio, que presenta sus propios desafíos en términos de despliegue, cola de PR y todo eso. Así que si no quieres pasar por todo eso, y quieres mantener un pequeño repositorio independiente que puedas desplegar de forma independiente para una parte de tu aplicación, entonces no puedes usar solo el enrutamiento de Firebase porque es simplemente un código diferente, ¿verdad? Sí. Así que creo que ahí es cuando los micro frontends aún pueden ser útiles con Remix. Sí. Eso tiene mucho sentido porque si estás trabajando en varios equipos, tienes que tener ese mono repositorio configurado, como dijiste, y tienes que tener un pipeline para sacar el code. Así que tienes que navegar por eso. Y eso es un montón de procesos
Soporte futuro de Remix y uso de Micro Front-End
Chris pregunta sobre el soporte futuro de Remix para Module Federation, pero el orador no es parte del equipo de Remix y no puede proporcionar detalles específicos. Mencionan la posibilidad de colaboración entre el ecosistema de Webpack Module Federation y el equipo de Remix. El orador aconseja a Chris que se mantenga actualizado con el RFC de Remix y el pipeline. También destacan que Tiny Frontend no requiere soporte de framework y se puede utilizar en Remix y otros frameworks. Sin embargo, mezclar varios frameworks puede afectar el rendimiento. El orador sugiere usar un solo framework para minimizar el costo de rendimiento. Comparten su experiencia de trabajar con diferentes frameworks dentro de la misma aplicación y recomiendan usar micro front-ends si resuelve problemas específicos para la empresa.
y cosas así. Entonces Chris pregunta, mencionaste hacia el final de la charla que Remix podría soportar algo de esto en el futuro. ¿Tienes más detalles sobre eso? Lamentablemente, no formo parte del equipo de Remix. Así que no puedo decirlo con seguridad. Pero creo que la gente en el ecosistema de Webpack Module Federation, por ejemplo, Zack, creo que han insinuado que han estado trabajando con el equipo de Remix para quizás añadir soporte para Module Federation en Remix, de la misma manera que hay un plugin que él hizo para soportar Next Module Federation, Next.js Module Federation. Así que si eso sale de la caja, entonces básicamente obtendrás esta capacidad de desplegar independientemente Remix up, pero se comportan como una sola federación dentro del framework. Pero no creo que haya un cronograma para ello. Okay. Sí. Ojalá te hubiéramos tenido antes de hacer la Charla junto al fuego con Chance porque podría haberle preguntado a Chance, pero creo que tienen su RFC y su pipeline que están sacando con las nuevas características públicas ahora. Así que estábamos hablando de eso antes. Así que tal vez sólo mantén un ojo en eso, Chris, si estás buscando cosas que están por venir en el futuro, y siempre puedes tal vez como presentar un problema o iniciar una discussion en su repositorio sobre eso también. Sí. Una pequeña cosa a añadir también es que el Tiny Frontend no requiere ningún soporte de framework. Así que eso ya funciona en Remix y Next y otros frameworks fuera de la caja. Es sólo como páginas federadas, como esta cosa de corte vertical que necesitas cambiar Remix para. Sí. En realidad, creo que otro buen punto de usar Remix es que algo de lo que hablamos antes es que está dando este paso para ser agnóstico de la plataforma, donde puedes ser capaz de usar otros frameworks, y si estás usando una arquitectura de micro-frontend, ser capaz de escribir otros lenguajes puede ser útil para tu empresa, ¿verdad?
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
Tiny Frontend y Webpack Module Federation
Tiny Frontend no utiliza la federación de módulos de webpack. Utiliza VIT y especifica cada dependencia compartida en las dependencias de aspia. La biblioteca proporciona una solución ligera exponiendo dependencias en el contexto global. Si la federación de módulos de webpack se convierte en un estándar, los componentes internos de tiny front-end pueden modificarse fácilmente para utilizarla.
de forma independiente porque seguimos pisándonos los pies, no es manejable. Como la PRQ se está volviendo loca y todo. Realmente queremos tener esta independencia de despliegue, entonces opta por el micro front-end como una herramienta que puede ayudarte, sabes, a eliminar esas dependencias o hacerlas más, digamos, sueltas. Así que sí.
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.
Comments