Escalando con Remix y Micro Frontends

Rate this content
Bookmark

¿Tienes un producto grande construido por muchos equipos? ¿Estás luchando para lanzar con frecuencia? ¿Tu frontend se ha convertido en un monolito masivo e inmantenible? Si, al igual que yo, has respondido sí a alguna de esas preguntas, ¡esta charla es para ti! Te mostraré exactamente cómo puedes construir una arquitectura de micro frontends con Remix para resolver esos desafíos.

23 min
18 Nov, 2022

Video Summary and Transcription

Esta charla discute el uso de Microfrontends en Remix e introduce la biblioteca Tiny Frontend. Kazoo, una plataforma de compra de autos usados, sigue un enfoque de diseño impulsado por el dominio y ha encontrado problemas con la segmentación granular. Tiny Frontend tiene como objetivo resolver el problema de segmentación y promover la seguridad de tipos y la compatibilidad de las dependencias compartidas. El orador demuestra cómo funciona Tiny Frontend con el renderizado en el lado del servidor y cómo Remix puede consumir y actualizar componentes sin volver a implementar la aplicación. La charla también explora el uso de micro frontends y el soporte futuro para Webpack Module Federation en Remix.

Available in English

1. Introducción a Remix y Microfrontends

Short description:

En esta charla, discutiremos cómo usar Microfrontends en Remix. Tengo experiencia como ingeniero de software senior en Tractable y como ingeniero de software principal en Kazoo, donde lideré el esfuerzo de Microfrontends.

¡Hola! Hola a todos. Y bienvenidos a esta charla, Avanzando con Remix y Microfrontends, en la cual hablaremos sobre cómo usar Microfrontends en Remix. Un poco sobre mí. Mi nombre es Soy un ingeniero de software senior en Tractable, que es una empresa genial que se dedica a la inteligencia artificial y el aprendizaje automático para seguros. Tomamos tecnología innovadora en un mercado bastante aburrido y tratamos de hacerlo más moderno. Antes de eso, fui ingeniero de software principal en Kazoo, y en esa empresa, lideré principalmente el esfuerzo de Microfrontends. Así que hablaré principalmente sobre mi trabajo allí.

2. Introducción a Kazoo

Short description:

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.

Primero, probablemente te estés preguntando, ¿qué es un kazoo? Probablemente haya pensado 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. Básicamente, para personas en los Estados Unidos, es un clon de Carvanha, pero en el Reino Unido. Y lo que hace es, básicamente comprar coches usados y luego venderlos en línea. Lo entregan en tu puerta y tienes siete días para probarlo. Si no te gusta, simplemente devuelves el coche, sin problemas, sin preguntas. Así que es simplemente tu comercio electrónico tradicional. Como para personas como nosotros que construimos cosas, ves esto y piensas, oh, es un sitio web de comercio electrónico. Sí, es un sitio web de comercio electrónico. Excepto que cada

3. Front-end en Kazoo e Introducción a Tiny Frontend

Short description:

Kazoo sigue un enfoque de diseño impulsado por dominio, con cada segmento vertical propiedad de un equipo específico. Ejemplos de segmentos incluyen búsqueda y navegación, mi cuenta y finanzas del consumidor. Kazoo implementa aplicaciones separadas de forma independiente, pero todas enraizadas en el mismo dominio. Enfrentaron problemas con el segmentado granular y presentaron el segmentado horizontal. El desafío de proporcionar un segmento horizontal se llama segmentado horizontal en el mundo de los microfrontends. Para resolver esto, el orador creó una biblioteca llamada tiny frontend, que es un paquete NPM que obtiene la última implementación implementada en tiempo de ejecución.

El artículo es como £10,000 o algo así, ¿verdad? Genial. Entonces, ¿cómo se ve el front-end en Kazoo? Desde el principio, Kazoo ha seguido un enfoque de diseño impulsado por dominio, lo que significa que cada segmento vertical del problema es propiedad de un equipo específico y ellos son dueños de toda la pila para ese problema específico. Entonces, son dueños del front-end, del back-end, de la implementación, de todo. Entonces, ¿cuáles son algunos ejemplos de segmento, podrías preguntar? Por ejemplo, podrías tener búsqueda y navegación, que es que buscas un vehículo, ves los detalles de un vehículo, todas estas cosas. Tendrías mi cuenta que te permite ver la información de tu cuenta y pedidos anteriores, o finanzas del consumidor, que es la solicitud de préstamo en línea. Entonces, cuando compras el vehículo, puedes solicitar un préstamo. Y hay muchosforms que te hacen muchas preguntas 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.

Desde una perspectiva de implementación, básicamente tienes el dominio Kazuko UK y diferentes aplicaciones separadas que se implementan de forma independiente y todas poseen un conjunto de páginas en el dominio. Entonces, si lo ves desde una perspectiva de remix, eso sería básicamente múltiples aplicaciones de remix implementadas por separado, como de forma independiente por equipos, pero todas apuntando al mismo, como todas enraizadas en el mismo dominio, si 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, segmentado 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 finanzas del consumidor, que proporciona esta solicitud de préstamo, ya sabes, para aumentar la conversión, porque queremos vender más préstamos, necesitamos mostrar una calculadora de financiamiento en los detalles de un vehículo dado, en la página de detalles del vehículo. O por ejemplo, cuando realizas un pedido y quieres cancelar tu entrega en mi cuenta, querrías ver algo que te permita seleccionar horarios disponibles. Y hay un equipo que se encarga de toda la logística de mover coches. Y este es el que conoce los horarios disponibles y cómo debería verse la interfaz de usuario para que las personas puedan reservar horarios. Entonces quieren implementar su cosa en mi cuenta. Finalmente, hay algo que casi todos tienen, un encabezado y un pie de página, que deben ser consistentes en todo el sitio web. Entonces, si estás en una empresa que implementa algunas aplicaciones en producción y tienes una marca consistente, como si ya haces este tipo de segmentado vertical, entonces probablemente ya tienes ese problema. Como probablemente tienes un encabezado y un pie de página en los que todos necesitan depender. Y ese problema de proporcionar un segmento de la página como este, un segmento horizontal de la página se llama segmentado horizontal en el mundo de los microfrontends. Sí. Lo primero que se te viene a la mente como ingeniero de front-end es, 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 así que contenga un componente de React, que es un encabezado y un pie de página y todos simplemente lo instalarán en la aplicación y lo renderizarán listo, ¿verdad? Sí, pero acabamos de introducir una dependencia de tiempo de compilación entre dos equipos al hacer esto, lo que significa que cualquier cambio en el encabezado por parte del equipo que lo posee necesita actualizarse y volver a implementar en cada aplicación que depende del encabezado. 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 individual y decir, por favor, ¿pueden actualizar e implementar su aplicación nuevamente? Lo cual es realmente doloroso y dificulta la capacidad del equipo para implementar rápidamente. Entonces, queremos que ese patrón de paquete de NPM funcione bastante bien. Pero queremos implementaciones independientes. Presentando tiny frontend. Entonces, para resolver ese problema exacto en KSU, construí una biblioteca llamada tiny frontend y básicamente apunté a resolver ese problema específico de microfrontend. ¿Qué es tiny frontend? Es un paquete de NPM que obtiene

4. Introducción a TinyFrontend

Short description:

TinyFrontend es una implementación con opiniones de la arquitectura de microfrontends que tiene como objetivo resolver el problema de segmentación. Sigue el principio de utilizar el marco de trabajo como un pegamento en tiempo de ejecución, esperando que el host tenga React. El host debe ser una aplicación vanilla de Remix o cualquier aplicación vanilla que utilice React. TinyFrontend tiene como objetivo ser fácil de consumir, como un paquete npm regular, y promueve la seguridad de tipos y la compatibilidad de dependencias compartidas en tiempo de compilación.

su última implementación implementada en runtime. Así que imagina un paquete NPM que insertas en tu proyecto pero que no contiene el código fuente real del componente React sino que obtiene el último en runtime. Es una implementación con opiniones de la arquitectura de microfrontends y tiene como objetivo resolver el problema de segmentación. No es la única forma correcta de hacer microfrontends, ya que el microfrontend es solo una arquitectura. Hay muchas soluciones diferentes por ahí que son diferentes compensaciones. Esta es solo una de ellas. No tiene como objetivo resolver el problema de segmentación vertical. Por ejemplo, no se preocupa por el enrutamiento o cualquier otra cosa de este tipo. Solo está aquí para proporcionar el componente en runtime. OK, algunos principios guía que sigue TinyFrontend. Utiliza el marco de trabajo como un pegamento en runtime. La idea es, por ejemplo, es posible que hayas oído hablar de los web components o cosas así, y hay bastantes soluciones que te permiten utilizar diferentes marcos de trabajo como una aplicación Angular que consume un componente React, o cosas así. Esto no es lo que TinyFrontend quiere hacer. Solo quiere decir genial, vas a implementar 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 otra cosa, pero es una suposición que estamos haciendo. ¿Por qué quieres hacer eso? Porque tener múltiples marcos de trabajo ejecutándose en la misma página no es bueno para el rendimiento, por lo que en general tener un marco de trabajo consistente para toda tu empresa mejora la experiencia del usuario. Segundo principio, no necesitas nada especial para consumir TinyFrontend. Una vez más, algunas implementaciones de Microfrontend requerirán que tengas una aplicación host grande que conozca muchas cosas. Básicamente es más como un marco de trabajo que una biblioteca, y TinyFrontend es más como una biblioteca. El host debe ser simplemente una aplicación vanilla de Remix, o cualquier otra aplicación vanilla que utilice 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. Tercer principio, ser seguro en cuanto a tipos. Nos gusta la seguridad de tipos. TypeScript es nuestro amigo. Si podemos proporcionar los tipos de nuestro componente al equipo que lo consume para que puedan asegurarse de que su código se ejecutará en él en runtime, eso sería genial. Asegurar que las dependencias compartidas sean compatibles en tiempo de compilación. Porque estamos proporcionando ese componente al

5. Gestión de Dependencias y Resumen de la Arquitectura

Short description:

La aplicación host puede tener diferentes versiones de React. La opción automática para cambios no disruptivos es ideal, donde los componentes se pueden actualizar sin requerir ninguna acción de los equipos que los utilizan. La opción manual para cambios disruptivos implica comunicar la necesidad de cambios en el código base y actualizar la versión del paquete. La arquitectura consta de una aplicación host, un microfrontend compuesto por componentes frontend y un contrato, y una API de Cloudflare para implementar y actualizar los 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, lo que facilita el desarrollo e implementación de nuevas versiones de los componentes frontend.

otro equipo, nuestro componente podría estar utilizando una versión de React. La aplicación host podría tener una versión diferente de React. Queremos alguna forma de verificar que esas dependencias sean compatibles en tiempo de compilación. Luego, la opción automática para cambios no disruptivos. Esta es la idea de, como, tengo un encabezado, no necesita ninguna información, es solo un componente React y el tipo es simplemente, como, genial, es un encabezado, muéstralo, mostrará el encabezado. Cada vez que alguien cambie una copia dentro del encabezado, el color, lo que sea, el contrato de ese componente no cambia. Entonces, el equipo que utiliza el encabezado no debería tener que hacer nada. Si actualizas la página, deberías ver el nuevo encabezado cuando publiquemos uno nuevo.

La opción manual para cambios disruptivos significa que cuando un equipo, en realidad, en el encabezado, en realidad necesita hacer algo nuevo para hacer ese trabajo. Por ejemplo, acabamos de traducir, como, internacionalizar nuestro sitio web y ahora el componente necesita saber en qué idioma debe mostrarse. De lo contrario, ya no puede hacer el trabajo. Bueno, en ese caso, deberemos comunicar al equipo que elige ese componente que, en realidad, no, por favor, debes proporcionar el idioma como parte del contrato de ese componente para que pueda hacer mi trabajo. Y en ese caso, básicamente haces una nueva versión del paquete y pides a los equipos que actualicen manualmente y cambien el código base porque en realidad necesitan cambiar algo en el código base para que el componente pueda funcionar.

¿Cómo se ve la architecture? Entonces, tenemos este increíble diagrama que es, como, todos dicen, oh, Dios mío, ¿qué está pasando aquí? Hay tantas cajas rosas. Las revisaremos una por una. La primera, el host. Entonces, la cosa que va a mostrar ese micrófono. Entonces, una aplicación Remix en este caso. La segunda es un frontend pequeño. 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 está compuesto por dos carpetas, una carpeta de la aplicación que contiene el código fuente real de tu componente React y un contrato, que es un paquete NPM que vas a publicar para las personas que quieran consumirlo en runtime y puedan hacerlo. Y finalmente, porque estamos hablando de implementar esos paquetes desde este pequeño frontend porque necesitamos poder cambiarlos, porque no están en el paquete NPM, pueden cambiar en algún lugar, necesitan estar en algún lugar para enviar esos paquetes. Y en este caso, es una pequeña API construida en Cloudflare e implementada en Cloudflare como un Cloudflare worker.

Genial. Entonces, nuestro ejemplo de host, en este caso, Remix, va a instalar el paquete NPM, que proporciona un método que es asíncrono, y cuando llamas a ese método, te devuelve un componente React que puedes usar en tu aplicación. Cuando llamas a ese método, ¿qué hace? Bueno, utiliza 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 React en runtime desde un paquete que está implementado en algún lugar y todo eso, todo eso se abstrae en la biblioteca. Entonces, cuando construyes un nuevo frontend pequeño, no necesitas reinventar la rueda todo el tiempo y copiar y pegar mucho código. Solo puedes tener como básicamente todo se abstrae en una biblioteca que usas. Entonces, cuando el equipo que tiene el frontend pequeño, por ejemplo, el equipo del encabezado, tiene una nueva versión del encabezado, simplemente la empujarán al repositorio, tendrán algún tipo de, por ejemplo, una acción de GitHub que va a empaquetar el nuevo componente, y luego implementar ese paquete en esta API de Cloudflare. Y se actualizará básicamente

6. Demo de TinyFrontend y Renderizado en el Lado del Servidor

Short description:

Luego, alguien, como un usuario, por ejemplo, vendrá a nuestra aplicación Remix y actualizará la página. Debido a que el paquete ha cambiado, obtendremos el nuevo paquete y simplemente renderizaremos la aplicación con el nuevo componente. Genial. Entonces aquí tenemos una aplicación frontend pequeña. Esa aplicación frontend pequeña es esta caja aquí en rosa. Todo lo que está dentro de eso es un componente que se implementa de forma independiente. Y es esta base de código. Y todo lo que está fuera es simplemente una aplicación Remix regular. Otra cosa interesante que podemos ver es que si desactivo JavaScript y actualizo la página, aún puedo ver ese componente. Por lo tanto, TinyFrontend funciona en el renderizado en el lado del servidor. Entonces, la aplicación Remix carga el componente, 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. Entonces, 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 fue implementado y todo. Por lo tanto, puedes ver que esta es la fuente real de ese componente.

el estado allí para decir, este es ahora el nuevo paquete. Luego, alguien, como un usuario, por ejemplo, now vendrá a nuestra aplicación Remix y actualizará la página. Debido a que el paquete ha cambiado, obtendremos el nuevo paquete y simplemente renderizaremos la aplicación con el nuevo componente. Genial. Bueno, ahora vamos a ir a una pequeña demostración. Porque tiene mucho más sentido cuando lo ves por ti mismo. Genial. Entonces aquí tenemos una aplicación frontend pequeña. Esa aplicación frontend pequeña es esta caja aquí en rosa. Todo lo que está dentro de eso es un componente que se implementa de forma independiente. Y es esta base de código. Y todo lo que está fuera es simplemente una aplicación Remix regular.

Entonces podemos ver que esta base de código tiene dos cosas, como vimos. El contrato, que es este paquete 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 las dos. Esto se debe a que esto es solo un componente React regular en tiempo de ejecución. Por lo tanto, la comunicación es simplemente, la aplicación Remix puede pasar devoluciones de llamada. Y haces la comunicación de la manera habitual en una aplicación React. Algunos frameworks de Microflaren tienen buses y cosas así. Pero aquí, porque usamos el framework como el pegamento, todo lo que tenemos que hacer es pasar devoluciones de llamada, por ejemplo, si quieres. Otra cosa interesante que podemos ver es que si desactivo JavaScript y actualizo la página, aún puedo ver ese componente. Por lo tanto, TinyFrontend funciona en el renderizado en el lado del servidor. Entonces, la aplicación Remix carga el componente, 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. Entonces, 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 fue implementado y todo.

7. Consumiendo el Componente en Remix

Short description:

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. Se sigue el mismo proceso 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. En el lado de Remix, si vamos a nuestra página renderizada en el lado del 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. Por ejemplo, espera una propiedad de nombre. Si la eliminamos, se quejará y dirá que debes proporcionar un nombre. ¿Y cómo lo obtenemos? Bueno, lo obtenemos desde el cliente o el servidor, dependiendo de si estamos en el cliente o 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 que básicamente 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 podemos renderizarlo. En el cliente, hacemos lo mismo, pero llamamos a la versión del cliente, y lo hacemos antes de rehidratar la aplicación Remix. Probablemente haya alguna optimización que se pueda hacer en torno a la página y todo, pero sí.

8. Actualizando Componente en Remix

Short description:

Podemos cambiar el texto y el color del componente sin volver a implementar la aplicación Remix. El componente se actualiza al enviar cambios al repositorio, lo que desencadena el flujo de CI/CD y despliega el nuevo paquete. La aplicación Remix recupera automáticamente la última versión del componente, lo que resulta en una interfaz de usuario actualizada.

Genial. Entonces, ahora, veámoslo cambiar realmente. Si vamos a la fuente de esta aplicación y vamos a nuestro componente, podemos cambiar, por ejemplo, el texto aquí, digamos, Hola Remix Europe. Y cambiemos también el color, así que si vamos aquí y cambiamos esto para que sea Rebecca Purple, entonces podremos confirmar este cambio. Así que, he confirmado este cambio y lo estoy enviando. Una vez más, ahora no estoy haciendo un cambio en la aplicación Remix, solo estoy cambiando ese componente. Entonces, acabo de enviar al repositorio que contiene el código fuente de este componente aquí, ¿verdad? Entonces, la aplicación Remix no se vuelve a implementar, no hay cambios allí, sigue siendo la misma aplicación. Si vamos a las acciones, podemos ver que hay una acción que se inició en GitHub Action. Actualmente se 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 correctamente. Entonces, ahora si vamos aquí y actualizamos, vemos que ahora es el nuevo componente. Así que presiona remix Europe y la botella ahora es de color púrpura y no tuvimos que tocar nuestra aplicación remix. Bastante genial, ¿verdad?

QnA

Remix y Slicing Vertical

Short description:

Con Remix, podemos lograr la implementación independiente de aplicaciones mientras mantenemos una aplicación Remix federada que funciona en diferentes límites. El orador demuestra una prueba de concepto y menciona la posibilidad de utilizar la federación de módulos de Webpack para un enfoque más respaldado por el framework. 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 host de Remix. El orador concluye la charla e invita a la audiencia a una sesión de preguntas y respuestas, animándolos a seguir en Twitter.

De acuerdo, eso es el slicing horizontal. ¿Pero qué pasa con el slicing vertical, preguntas? Con remix, ¿podemos hacer algo al respecto? No sé si lo recuerdas, pero teníamos esta aplicación remix muy independiente, ¿verdad? Y idealmente, lo que querríamos, uno de los problemas que tenemos con esto es cuando las personas entre aplicaciones, en realidad tendrían que descargar React nuevamente, ¿verdad? Como cada aplicación enviará su propio React y remix y React Router y todas esas dependencias. Idealmente, queremos que los equipos puedan implementar su propia aplicación de forma independiente pero en tiempo de ejecución sea una aplicación remix federada que funcione en diferentes límites.

Entonces, querríamos tener algún tipo de host de remix en ejecución que pueda cargar páginas tanto de un remoto A como de un remoto B y manejar todo por nosotros. Así que construí una prueba de concepto muy pequeña y básica que muestra que es bastante fácil lograr eso en remix. Principalmente necesitas cambiar algunas cosas en el código fuente de remix. Aunque, si realmente te sientes aventurero, puedes usar mi demostración para intentar hacerlo tú mismo. Pero si esperas, he escuchado que es posible que... como la federación de módulos de Webpack, para remix y permitirte hacer eso de una manera más respaldada por el framework. De acuerdo. Hora de la demostración de eso. Genial. Aquí está mi aplicación Playground de federación de remix y tenemos dos aplicaciones. Tenemos un host y un remoto. El host es el que se está ejecutando actualmente y puedes ver en sus rutas de la aplicación, solo tiene un índice con un enlace a una página remota que no existe en esta base de código. También tenemos otra base de código llamada remix remoto y esa contiene una página remota que está ahí. ¿Qué sucede 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 una navegación regular, como, no hay recarga de página, nada, es del lado del cliente, esta es una navegación regular de remix. Así que se comporta como si la página remota fuera parte de la aplicación host de remix. Incluso 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 host. Y tenemos cosas, todo lo que esperas de remix, como las funciones de acción también funcionan. Por ejemplo, envío este formulario. En realidad, va a llamar a esta acción, y esa función se ejecutará dentro de la aplicación host. No voy a entrar en detalles sobre cómo funciona esto porque no tengo tiempo. Pero si buscas en la discusión en el repositorio de remix en GitHub, podrías encontrar cómo funciona esto. Y eso fue todo. Ahora pasaremos a las preguntas y respuestas. Gracias a todos por escuchar mi charla. Asegúrense de seguirme en Twitter

Resultados de Slido y Uso de Micro Frontends

Short description:

Discutimos los resultados de Slido sobre el uso de micro frontends. El 75% de las personas dijo que no, mientras que el 25% dijo que sí. El orador enfatiza que no todos necesitan usar micro frontends y que depende de la empresa y sus puntos problemáticos. Comparten su experiencia trabajando en Netlify, donde no se utilizan micro frontends, y en Grainger, donde sí se utilizaron. La decisión de usar micro frontends 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 comienzo de su charla. Vamos a ver los resultados de ¿estás utilizando micro frontends en tu empresa? Voy a cambiar a esa vista y ver cuáles son los resultados. Entonces no, el 75% de las personas dijo que no a eso. Es increíble. Y luego el 25% de las personas dijo que sí. ¿Te sorprende eso? Supongo que depende de la empresa para la que trabajas, ¿verdad? Creo que no todos necesitan usar micro frontends. Usa micro frontends solo si realmente resuelve un punto problemático en tu empresa. Así que está bien no usarlos. Supongo que depende de la audiencia y de dónde son y dónde trabajan, supongo. Supongo que eso es muy cierto. Actualmente trabajo en Netlify. Y no usamos micro frontends. Pero trabajé en Grainger antes y los usamos allí. Así que depende mucho de la empresa para la que trabajas.

Favorite Remix Feature: Form and Mutations

Short description:

La característica favorita de Remix entre la audiencia y los oradores es Form y Mutations. Se elogia por su simplicidad y facilidad de uso, especialmente en comparación con otros frameworks como Next.js. La capacidad de cambiar datos utilizando un formulario y que funcione incluso sin JavaScript se considera una gran fortaleza del framework Remix.

y cuál es su arquitectura. Así que eso tiene mucho sentido. Tenemos otra pregunta que hicimos a la audiencia al principio. Y también se la hemos estado haciendo a nuestros oradores durante 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 todos hicieron, que es Form y Mutations. ¡Yay! Vaya, qué originalidad. Sí, por la mayoría de las razones, creo que la gente ha dicho que 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 frameworks similares, piensas, no hay nada nuevo aquí. Pero luego te preguntas cómo cambio los datos. Y luego piensas, oh, espera, esto es, como, mucho más fácil. Simplemente usa un formulario. Y luego desactivas JavaScript. Y piensas, oh dios mío, funciona incluso en ese caso. Y hace muchas cosas por sí mismo bajo el capó. Lo cual es realmente, realmente agradable. Creo que definitivamente es mi característica favorita. Creo que es una de las grandes fortalezas del framework. Estoy de acuerdo con eso también. Creo que especialmente si trabajas con formularios día tras día, y ves que eso necesita suceder en tu framework, y luego no tienes eso disponible o es difícil de implementar, entonces Remix simplemente

Arquitectura de Remix y Micro Frontends

Short description:

¿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 trabajan en el mismo código, usar un mono repositorio sería la única forma de lograrlo con una sola aplicación de Remix. Sin embargo, un mono repositorio presenta desafíos en términos de implementación y cola de PR. Entonces, si desea mantener un repositorio pequeño e independiente para una parte de su aplicación, los micro frontends aún pueden ser útiles con Remix.

lo hace tan fácil. 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 problemáticos, 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 probablemente tenga, no quiero decir, en los sitios web públicos, probablemente al menos diez equipos de siete u ocho personas. Eso es muchas personas trabajando en el mismo código. La única forma de hacer eso con una sola aplicación de Remix sería mediante un mono repositorio, lo cual presenta sus propios desafíos en términos de implementación, cola de PR y todo eso. Entonces, si no quieres pasar por todo eso, y quieres mantener un repositorio pequeño e independiente que puedas implementar de forma independiente para una parte de tu aplicación, entonces no puedes usar solo el enrutamiento basado en archivos porque es un código diferente, ¿verdad? Sí. Creo que es ahí cuando los micro frontends aún pueden ser útiles con Remix. Sí. Eso tiene mucho sentido porque si estás trabajando en varios equipos, debes tener configurado ese mono repositorio, como dijiste, y debes tener un pipeline para llevar el código allí. Así que tienes que navegar eso. Y eso implica muchos procesos.

Soporte Futuro de Remix y Uso de Micro Front-Ends

Short description:

Chris pregunta sobre el soporte futuro de Remix para Module Federation, pero el orador no forma 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 mantenerse actualizado con el RFC y el pipeline de Remix. También destacan que Tiny Frontend no requiere soporte de framework y se puede utilizar en Remix y otros frameworks. Sin embargo, mezclar múltiples frameworks puede afectar el rendimiento. El orador sugiere utilizar 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 utilizar 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 admitir algunas de estas cosas en el futuro. ¿Tienes más detalles al respecto? Lamentablemente, no formo parte del equipo de Remix, así que no puedo decir con certeza. Pero creo que las personas en el ecosistema de Webpack Module Federation, por ejemplo, Zack, creo que han insinuado que han estado trabajando con el equipo de Remix para agregar soporte para Module Federation en Remix, de la misma manera que hay un complemento que él hizo para admitir Next Module Federation, Next.js Module Federation. Entonces, si eso sale de la caja, básicamente obtendrás esta capacidad de implementar Remix de forma independiente, pero se comportarán como una sola aplicación federada dentro del framework. Pero no creo que haya una línea de tiempo para eso. Bueno, sí. Ojalá te hubiéramos tenido antes de hacer la charla Fireside con Chance porque podría haberle preguntado, pero creo que tienen su RFC y su pipeline que están lanzando las nuevas características públicamente ahora. Así que estábamos hablando de eso antes. Así que tal vez solo esté atento a eso, Chris, si estás buscando cosas que vendrán en el futuro, y siempre puedes presentar un problema o iniciar una discusión en su repositorio al respecto. Sí. Una pequeña cosa más para agregar es que el tema de los micro front-end de Tiny no requiere soporte de framework. Por lo tanto, ya funciona en Remix, Next y otros frameworks de forma nativa. Es como páginas federadas, como esta cosa de división vertical que necesitas cambiar en Remix. Sí. De hecho, creo que otro buen punto de usar Remix es que algo de lo que hablamos antes es que está dando este paso hacia ser agnóstico de plataforma, donde tal vez puedas usar otros frameworks y, si estás utilizando una arquitectura de micro front-end, poder escribir en otros lenguajes puede ser útil para tu empresa, ¿verdad? Sí, eso es un buen punto. Aunque creo que generalmente abogo por no usar micro front-end para mezclar frameworks, a menos que estés haciendo algún tipo de migración en la que decidas migrar explícitamente de React a Zvelt, o digas 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 que creo que permitir múltiples frameworks permite una mayor libertad para los desarrolladores, pero tiene un costo de rendimiento para tus usuarios, porque luego tienen que cargar múltiples frameworks en el cliente para que todo funcione junto. Entonces, en general, creo que es mejor usar un solo framework, para que solo tengas el costo del framework una vez, si tiene sentido. Creo que eso tiene sentido. La razón por la que lo mencioné es porque cuando estaba en Grainger, teníamos, por ejemplo, React, jQuery, componentes de Hybris, componentes de Svelte. Así que teníamos todo funcionando juntos y las cosas habían sido hechas por empresas contratistas u otras empresas. Y luego nuestro equipo estaba trabajando en la parte de Svelte y luego terminaron cambiando a React. Así que estábamos trabajando con todos estos dentro de la misma aplicación y eso podría ser algo en el futuro. Así que me preguntaba cuáles son tus pensamientos al respecto, pero estoy de acuerdo, si tienes la opción de quedarte con un solo framework, es mucho menos trabajo para tu empresa. Entonces, ¿sugerirías que las personas utilicen un micro front-end en su empresa? Creo que Ruben Cazas, quien también habla mucho sobre micro front-end, también tiene algunas charlas sobre si deberías 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. Entonces, si tienes solo unos pocos equipos y pueden compartir un monorepo y todos pueden contribuir y no hay puntos problemáticos allí, simplemente haz un monorepo, haz esto y está bien. Si comienzas a sentir el dolor de que necesitamos poder implementar

Tiny Frontend y Webpack Module Federation

Short description:

Tiny Frontend no utiliza webpack module federation. Utiliza VIT y especifica cada dependencia compartida en las dependencias de aspia. La biblioteca proporciona una solución ligera al exponer las dependencias en el contexto global. Si webpack module federation se convierte en un estándar, los componentes internos de tiny front-end se pueden modificar fácilmente para utilizarlo.

de forma independiente porque nos estamos pisando los pies mutuamente, no es manejable. Como el PRQ se está volviendo loco y todo. Realmente queremos tener esta independencia de implementación, entonces, si te gusta, el micro front-end es una herramienta que puede ayudarte, ya sabes, eliminar esas dependencias o hacerlas más flexibles. 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 anterior sobre la webpack module federation. ¿Tiny Frontend utiliza webpack module federation? Buena pregunta. No, no lo hace. Podría ser, como la implementación subyacente podría usar webpack module federation. Cuando lo construí, decidí no hacerlo. La razón principal es que no utiliza webpack para empaquetar, en realidad utiliza, creo, ESBuild. Quiero decir, utiliza 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 unir un poco para exponerlas en el contexto global y luego conectarlas por ti. Y webpack module federation puede hacer muchas cosas por ti, puede hacer resolución dinámica de versiones y todo ese tipo de cosas. Y eso realmente no era necesario para tiny front-end porque no puedes tener una relación uno a uno entre el host y el paquete que se incluye. Por eso no lo elegí, es un poco más ligero. Pero para ser justos, ya sabes, si por ejemplo, webpack module federation se convierte en un estándar y todos comienzan a usarlo, sería bastante trivial cambiar los componentes internos de tiny front-end para usarlo en lugar de eso. Sí, eso es increíble, bueno, creo que eso es todo el tiempo que tenemos hoy. Muchas gracias Adrian por acompañarnos en la sesión de preguntas y respuestas y gracias por la charla. Sí, gracias, gracias por tenerme, saludos.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
React Advanced Conference 2022React Advanced Conference 2022
29 min
Understanding React’s Fiber Architecture
Top Content
We've heard a lot about React's Fiber Architecture, but it feels like few of us understand it in depth (or have the time to). In this talk, Tejas will go over his best attempt at understanding Fiber (reviewed by other experts), and present it in an 'explain-like-I'm-five years old' way.
JSNation Live 2021JSNation Live 2021
29 min
Making JavaScript on WebAssembly Fast
Top Content
JavaScript in the browser runs many times faster than it did two decades ago. And that happened because the browser vendors spent that time working on intensive performance optimizations in their JavaScript engines.Because of this optimization work, JavaScript is now running in many places besides the browser. But there are still some environments where the JS engines can’t apply those optimizations in the right way to make things fast.We’re working to solve this, beginning a whole new wave of JavaScript optimization work. We’re improving JavaScript performance for entirely different environments, where different rules apply. And this is possible because of WebAssembly. In this talk, I'll explain how this all works and what's coming next.
React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.

Workshops on related topic

React Summit 2022React Summit 2022
136 min
Remix Fundamentals
Top Content
Featured WorkshopFree
Building modern web applications is riddled with complexity And that's only if you bother to deal with the problems
Tired of wiring up onSubmit to backend APIs and making sure your client-side cache stays up-to-date? Wouldn't it be cool to be able to use the global nature of CSS to your benefit, rather than find tools or conventions to avoid or work around it? And how would you like nested layouts with intelligent and performance optimized data management that just works™?
Remix solves some of these problems, and completely eliminates the rest. You don't even have to think about server cache management or global CSS namespace clashes. It's not that Remix has APIs to avoid these problems, they simply don't exist when you're using Remix. Oh, and you don't need that huge complex graphql client when you're using Remix. They've got you covered. Ready to build faster apps faster?
At the end of this workshop, you'll know how to:- Create Remix Routes- Style Remix applications- Load data in Remix loaders- Mutate data with forms and actions
DevOps.js Conf 2024DevOps.js Conf 2024
163 min
AI on Demand: Serverless AI
Featured WorkshopFree
In this workshop, we discuss the merits of serverless architecture and how it can be applied to the AI space. We'll explore options around building serverless RAG applications for a more lambda-esque approach to AI. Next, we'll get hands on and build a sample CRUD app that allows you to store information and query it using an LLM with Workers AI, Vectorize, D1, and Cloudflare Workers.
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Featured Workshop
The modern web would be different without rich client-side applications supported by powerful frameworks: React, Angular, Vue, Lit, and many others. These frameworks rely on client-side JavaScript, which is their core. However, there are other approaches to rendering. One of them (quite old, by the way) is server-side rendering entirely without JavaScript. Let's find out if this is a good idea and how Remix can help us with it?
Prerequisites- Good understanding of JavaScript or TypeScript- It would help to have experience with React, Redux, Node.js and writing FrontEnd and BackEnd applications- Preinstall Node.js, npm- We prefer to use VSCode, but also cloud IDEs such as codesandbox (other IDEs are also ok)
Remix Conf Europe 2022Remix Conf Europe 2022
195 min
How to Solve Real-World Problems with Remix
Featured Workshop
- Errors? How to render and log your server and client errorsa - When to return errors vs throwb - Setup logging service like Sentry, LogRocket, and Bugsnag- Forms? How to validate and handle multi-page formsa - Use zod to validate form data in your actionb - Step through multi-page forms without losing data- Stuck? How to patch bugs or missing features in Remix so you can move ona - Use patch-package to quickly fix your Remix installb - Show tool for managing multiple patches and cherry-pick open PRs- Users? How to handle multi-tenant apps with Prismaa - Determine tenant by host or by userb - Multiple database or single database/multiple schemasc - Ensures tenant data always separate from others
Remix Conf Europe 2022Remix Conf Europe 2022
156 min
Build and Launch a personal blog using Remix and Vercel
Featured Workshop
In this workshop we will learn how to build a personal blog from scratch using Remix, TailwindCSS. The blog will be hosted on Vercel and all the content will be dynamically served from a separate GitHub repository. We will be using HTTP Caching for the blog posts.
What we want to achieve at the end of the workshop is to have a list of our blog posts displayed on the deployed version of the website, the ability to filter them and to read them individually.
Table of contents: - Setup a Remix Project with a predefined stack- Install additional dependencies- Read content from GiHub- Display Content from GitHub- Parse the content and load it within our app using mdx-bundler- Create separate blog post page to have them displayed standalone- Add filters on the initial list of blog posts
React Day Berlin 2022React Day Berlin 2022
86 min
Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
Top Content
WorkshopFree
Using a library might seem easy at first glance, but how do you choose the right library? How do you upgrade an existing one? And how do you wade through the documentation to find what you want?
In this workshop, we’ll discuss all these finer points while going through a general example of building a code editor using CodeMirror in React. All while sharing some of the nuances our team learned about using this library and some problems we encountered.