Muchas empresas en todo el mundo están considerando adoptar Micro-Frontends para mejorar la agilidad empresarial y la escala, sin embargo, hay muchas incógnitas cuando se trata de cómo se ve en la práctica el camino de migración. En esta charla, discutiré los pasos necesarios para migrar con éxito una aplicación React monolítica a una arquitectura de frontend más modular y desacoplada.
This talk has been presented at React Advanced Conference 2022, check out the latest edition of this React Conference.
FAQ
Un micro-frontend es una técnica de arquitectura de desarrollo que consiste en descomponer las aplicaciones front-end en piezas más pequeñas e independientes, cada una con su propia base de código, que pueden desplegarse y escalarse de manera independiente.
El principal problema es el acoplamiento, especialmente el acoplamiento accidental, que dificulta la escalabilidad y la gestión de las dependencias en las aplicaciones grandes.
El desacoplamiento es crucial porque permite una mayor flexibilidad y escalabilidad en la aplicación, reduciendo la complejidad y facilitando la transición a micro-frontends sin comprometer la estructura y la funcionalidad existentes.
Los despliegues independientes permiten actualizar o modificar partes específicas de la aplicación sin necesidad de redeployar toda la aplicación, lo que mejora el tiempo de desarrollo y minimiza los riesos relacionados con los cambios en la aplicación.
Algunas estrategias incluyen el uso del patrón Strangler para reemplazar gradualmente partes del monolito con micro-frontends, y la selección cuidadosa del enrutamiento y la composición en la aplicación para manejar diferentes partes del sistema de manera independiente.
El patrón Strangler consiste en desarrollar nuevas funcionalidades como micro-frontends que reemplazan gradualmente las funciones del sistema monolítico antiguo, permitiendo una transición suave y controlada hacia una arquitectura más moderna y modular.
Se considera a los Microfrontends como una solución a los problemas de crecimiento exponencial, duplicación de código y propiedad poco clara en aplicaciones antiguas. La transición de un monolito a microfrontends implica desacoplar el sistema y explorar opciones como un monolito modular. Los Microfrontends permiten implementaciones independientes y composición en tiempo de ejecución, pero hay una discusión sobre la alternativa de mantener una aplicación integrada compuesta en tiempo de ejecución. Elegir un modelo de composición y un enrutador son decisiones cruciales en el plan técnico. Se utilizan el patrón Strangler y el patrón Strangler inverso para reemplazar gradualmente partes del monolito con la nueva aplicación.
Vamos a hablar sobre cómo transformar monolitos en micro-frontends. React ha estado aquí durante mucho tiempo y las aplicaciones que ahora son un poco antiguas comienzan a crecer y a romperse. Los problemas suelen estar relacionados con la organización y las complicaciones que vienen con el crecimiento. El crecimiento exponencial, la duplicación de código y la propiedad poco clara son algunos de los problemas. Muchas personas y empresas han considerado a los microfrontends como una solución.
Entonces, mi nombre es Ruben y soy ingeniero en Postman. Y el tema de hoy es interesante. Vamos a hablar sobre cómo transformar monolitos en micro-frontends. Ahora, esta es nuestra conferencia de React, ¿verdad? Bueno, React ha estado aquí durante mucho tiempo, ¿verdad? El próximo año, React tendrá ¿cuántos años? Diez años, ¿verdad? Entonces, los reclutadores probablemente dirán, oh, finalmente, vamos a pedir diez años de experiencia en React. React ha estado aquí durante mucho tiempo. Si tienes aplicaciones que ahora son un poco antiguas. Bueno, técnicamente, no viejas, viejas, pero en el largo esquema de las cosas de la tecnología, probablemente están envejeciendo un poco. Y el problema con eso es que las aplicaciones envejecen y comienzan a crecer y crecer y crecer. Y ¿cuál es el problema con el crecimiento? Bueno, probablemente empiece a romperse en algún momento. Y probablemente estaremos experimentando. Ahora, si piensas, si has estado trabajando con React, piensa en los problemas que tienes ahora, probablemente tendrás una larga sesión de personas simplemente quejándose sobre los problemas que tienes. Pero en su mayoría no se trata de React en sí, suele ser sobre la organización. Se trata de cómo a medida que tu empresa y la aplicación crecen, las cosas comienzan a complicarse y a ser difíciles de escalar. Entonces, empiezas a tener cosas como crecimiento exponencial, como tienes muchas líneas de código. Tienes más desarrolladores, sabes, cuando empezaste ese proyecto solo eran dos o tres. Ahora tienes muchos grupos de desarrolladores, especialmente para empresas que son bastante grandes. CI tarda mucho tiempo en completarse. Todos odiamos eso. Queremos que las cosas sean rápidas. Duplicación de código. No hay una propiedad clara. ¿Quién posee qué? Etcétera, etcétera. Entonces, tenemos muchos problemas. Ese gráfico de dependencias es el peor. Lo odio. Como que tenemos muchas dependencias y no sabemos de dónde vienen o qué está usando qué. Entonces, hay muchos problemas. Probablemente estés familiarizado con esto. Entonces, todos estos problemas han llevado a muchas personas a pensar en microfrontends. ¿Deberíamos usar microfrontends para resolver este problema? Y muchas personas y empresas
2. Transición de Monolito a Microfrontends
Short description:
¿Cómo pasamos de un monolito a microfrontends? El objetivo principal de pasar del monolito a los microfrontends es eliminar el acoplamiento y el acoplamiento accidental. La gente quiere pasar a los microfrontends, pero no entienden por qué. Si quieres pasar a una arquitectura distribuida, si quieres resolver esos problemas que tienes con la escalabilidad de una gran aplicación monolítica, primero necesitas desacoplarla.
están implementando microfrontends o están intentando implementar microfrontends. Y solo hay un problema con eso. ¿Cómo lo hacemos? ¿Por dónde empezamos? Tengo este gran problema, este monolito, esta aplicación masiva. ¿Cómo pasamos de un monolito a microfrontends?
Bueno. Pero, primero, ¿qué son los microfrontends? Esto es una broma. No voy a explicar qué es un microfrontend. Cada charla sobre microfrontends comienza con esa diapositiva. Si no estás familiarizado, puedes ver algunas charlas sobre qué son. Voy a estar más enfocado en cómo llegar allí, en lugar de qué son. Y puedo tocar un par de conceptos. Pero ese es el objetivo principal de esto... De hecho, voy a decirte cuál es el objetivo principal de esta presentación. ¿Quieres saber cuál es el objetivo principal de esta presentación? Voy a hacerte inteligente. Voy a hacerte lucir bien. Cuando vayas a la próxima reunión, ¿verdad?, si quieres impresionar a todos en esa sala, ¿verdad?, te lo mostraré. Te daré la clave. ¿Estás listo para la clave? Una vez que estés en esa reunión, solo tienes que decir, bueno, creo que necesitamos encontrar una oportunidad para desacoplar estas piezas. Bien. Inmediatamente. Eso te hará sonar como la persona más inteligente de esa sala. Así que desacoplar las piezas, y eso es Ryan Florence, por cierto. Gran cita. Eso no soy yo. Así que el acoplamiento es un gran problema. Y, de hecho, lo más grande que el acoplamiento es el acoplamiento accidental. Eso es lo peor de todo. Así que el objetivo principal de, bueno, no de esta charla, sino el objetivo principal de pasar del monolito a los microfrontends es eliminar el acoplamiento y el acoplamiento accidental. Ese es el objetivo principal, ¿verdad? ¿Cómo logramos ese objetivo? Bueno, te lo mostraré en un minuto, pero lo que me gusta decir, esta es mi cita, por cierto, creo, así que se me ocurrió. La gente quiere pasar a los microfrontends, pero no entienden por qué. Y esta es una razón realmente suficiente. Si quieres pasar a una arquitectura distribuida, si quieres, ya sabes, resolver esos problemas que tienes con la escalabilidad de una gran aplicación monolítica, primero necesitas desacoplarla,
3. Desacoplamiento y el Monolito Modular
Short description:
Antes de aplicar micro frontends, comienza con el desacoplamiento del sistema. Los micro frontends buscan desacoplar el monolito y dar sentido al gráfico de dependencias. Sin embargo, es importante considerar otras opciones y explorar los pasos intermedios. Un enfoque es un monolito modular, que ayuda a organizar la aplicación dentro del monolito.
de lo contrario, terminarás en un lugar peor del que empezaste. Y de hecho, tengo una charla sobre, ya sabes, los riesgos de adoptar micro frontends cuando realmente no los necesitas. Así que antes de que podamos aplicar micro frontends, deberíamos empezar con el desacoplamiento del sistema. ¿Y qué es el acoplamiento? Bueno, hay muchos tipos diferentes de acoplamiento. Pero si empiezas a notar que las cosas empiezan a cambiar juntas, ya sabes, como code que cambia junto se queda junto, pero si ese code se queda junto, empiezas a tener muchas dependencias entrelazadas y las cosas empiezan a ser realmente difíciles de desplegar independientemente o de tener algún sentido de cómo es el sistema. Así que, antes de ir a distribuir el sistema, antes de ir a los micro frontends, creo que si hacemos nuestro objetivo desacoplar nuestras bases de código, eso sería un objetivo logrado. Así que, recuerda, acoplamiento. Así que, ese es el objetivo principal. El principal objetivo de los micro frontends es desacoplar el monolito. Tratar de dar sentido a ese gráfico de dependencias no me gusta tener ese gran problema y tratar de desacoplar el monolito. Hay muchas formas de lograr ese objetivo de desacoplar el monolito. De nuevo, los micro frontends son uno de ellos. Pero, hoy, solo te challenge. Por favor, intenta todas las otras opciones.
No vayas y digas, OK, los micro frontends son la solución. Hay muchas soluciones. Yo llegué a un gráfico, como un diagrama, que llamé el espectro desacoplado y distribuido, que es un largo lugar donde puedes ir de uno al siguiente hasta que resuelvas tu problema. Explicaré este gráfico brevemente. Así que, tenemos el monolito, ¿verdad? Eso es donde estamos ahora mismo. Algunas personas tienen el monolito con backend y frontend todavía. Pero vamos a suponer que no tenemos eso. Supongamos que el backend ya está dividido en microservices. Todavía tenemos el monolito y la aplicación frontend en el monolito. Estamos luchando porque no podemos desplegar, es muy difícil, todos estos problemas que discutimos brevemente. Si salto directamente a los micro frontends y no he explorado todos los pasos en el medio, estoy llegando a esta conclusión que podría no ser la solución para mi problema. Recuerda, uno de los principales problemas es el desacoplamiento. ¿Cómo desacoplamos? Vamos paso a paso. Probemos un monolito modular. Este enfoque también es realmente bueno. Algunas empresas lo están usando. Y tienen su aplicación un poco más organizada dentro de su monolito.
4. Transición a Microfrontends
Short description:
Los monolitos modulares proporcionan cierta propiedad de equipo y límites dentro de una aplicación monolítica, pero todavía tienen acoplamiento y no pueden ser desplegados de forma independiente. Las aplicaciones integradas ofrecen más flexibilidad, pero aún se despliegan como una única unidad. Los microfrontends permiten despliegues independientes y composición en tiempo de ejecución, permitiendo despliegues separados de unidades individuales. Sin embargo, los despliegues independientes no siempre pueden ser la mejor solución, y hay una masterclass después de esta que discute la alternativa de mantener una aplicación integrada compuesta en tiempo de ejecución. Ahora, vamos a centrarnos en cómo hacer la transición de un monolito a microfrontends con un plan de acción.
Todavía es un monolito, todavía se despliega como una sola unidad, pero tienen cierta propiedad de equipo, tienen algunos límites, pueden entender un poco mejor la aplicación, y todavía tienen cierto acoplamiento, por lo que todavía estamos en la escala de acoplamiento scale en lugar de la escala de desacoplamiento scale, pero no pueden desplegarse de forma independiente. Eso es una de las cosas principales con los monolitos modulares, tienes que desplegar todo el conjunto, y todavía tienes mucho acoplamiento dentro, por lo que toda la UI y las bibliotecas y todo está ahí. Pero para tu empresa, para tu caso de uso, un monolito modular podría ser perfectamente adecuado y podría funcionar y podría resolver muchos de tus problemas. Así que, compruébalo si quieres. Echa un vistazo a un monolito modular. Y luego el siguiente paso es, oh, ¿qué tal las aplicaciones integradas? Las aplicaciones integradas son un poco más flexibles que un monolito modular. Hay muchos sabores y muchas herramientas de monorepo intentan ayudarte con una aplicación integrada, que básicamente tienes múltiples aplicaciones todavía dentro de una base de code. Podría ser un monorepo. Y se despliegan y componen en tiempo de construcción. Así que, todavía no puedes desplegar de forma independiente. Todavía puedes desplegar, pero una vez que lanzas la aplicación, esto es clave, se lanza como esa única unidad todavía. Así que, esa es la principal diferencia. Ahora, finalmente hemos llegado a los microfrontends. Entonces, ¿qué obtienes si aplicas microfrontends? Si no te detienes en las aplicaciones integradas y los monorepos. Y la clave son los despliegues independientes. Así que, tendrás despliegues independientes y composición en tiempo de ejecución con microfrontends, lo que significa que no tienes que desplegar esa única unidad de nuevo de una vez. Puedes desplegar esas unidades independientes por separado. Y eso podría ser lo que necesitas. O puede que no sea lo que necesitas. ¿Correcto? Así que, podría ser que los despliegues independientes en realidad vayan a causar muchos problemas. Y de hecho, hay una gran charla justo después de mi charla de mi buen amigo Alex. Él va a hablar exactamente de eso, que es ¿qué pasa si no vamos a los despliegues independientes? ¿Qué pasa si simplemente mantenemos una aplicación integrada que se compone en tiempo de ejecución? Así que, no te la pierdas. Es después de esta charla. Pero, prometí que iba a mostrarte cómo pasar de un monolito a un microfrontend. Hemos decidido que necesitamos microfrontends. Necesitamos despliegues independientes. ¿Cómo lo hacemos? Correcto. Así que, necesitamos un plan de acción. Y este plan de acción es dos cosas.
5. Plan Técnico: Elección de un Modelo de Composición
Short description:
Necesitamos un plan técnico y organizativo. Si estás desplegando de forma independiente y componiendo cosas, necesitas encontrar un modelo de composición. Para una aplicación de página única de React, la renderización en el lado del cliente con modus operation de Webpack es una buena elección. Modus operation permite flexibilidad y decisiones reversibles, evitando la inversión en la tecnología equivocada.
Necesitamos un plan técnico y organizativo. Y espero poder repasar lo técnico. Y al final, hablaremos de lo organizativo. Entonces, lo primero es, si estás desplegando de forma independiente y estás componiendo cosas, necesitas encontrar cómo vas a hacerlo, ya sabes, cómo vas a juntar todo. Y esta es una forma muy común de dividir microfrontends, que es, ya sabes, verticalmente por, ya sabes, la ruta, el enrutador y la URL, o horizontalmente, como widgets y cosas así. Pero hay muchas formas de hacer esto. Puedes hacerlo en el borde. Puedes hacerlo en el lado del servidor. Puedes hacerlo en el lado del cliente. Necesitas elegir un modelo de composición. Entonces, imaginemos que tenemos una aplicación de React. Para mantenerlo simple, es una aplicación de una sola página. No se renderiza en el lado del servidor. Voy a elegir un modelo de composición basado en la renderización en el lado del cliente y voy a utilizar modus operation de Webpack, que es una gran herramienta y te diré por qué me gusta. Pero, básicamente, vamos a mantenerlo simple. La composición de renderización en el lado del servidor es posible. Es solo un poco más difícil. Pero, si tienes una aplicación de una sola página, una aplicación de React, y quieres elegir un modelo de composición, este es uno bueno para optar con modus operation de Webpack. Te dije por qué iba a decir por qué me gusta modus operation. Una cosa importante y es muy flexible. Y una cosa importante en este viaje de monolito a microtransparencia, necesitas asegurarte de que tomas decisiones reversibles. Que haces la transición gradualmente. Modus operation te permite tener esa flexibilidad. Porque estoy importando un módulo externo usando modus operation, y ahora estoy importando, oh, es la misma diapositiva. En realidad, no es la misma diapositiva. Estoy importando un módulo local. Si decido que modus operation no es lo mío y no está funcionando para mí, bueno, es realmente fácil volver a la composición en tiempo de construcción y cargar desde MPM en lugar de desde modus operation. Así que, tomar decisiones que son reversibles es muy, muy importante. Porque no quieres embarcarte en un viaje de, de nuevo, ir a micro front ends y te das cuenta a mitad de camino de que esto no es para nosotros. Has invertido mucho en nuestra tecnología y arquitectura que probablemente no será muy buena
6. Elección de un Router para Microfrontends
Short description:
Modus operation te permite componer componentes de React en tiempo de ejecución en lugar de en tiempo de construcción. Elegir un router es una decisión crucial al pasar de un monolito a microfrontends. Hay tres opciones: un router de nivel superior, un router de sub-aplicación y un router de micro-frontend. El router de nivel superior es similar a un router normal, pero tiene más acoplamiento y requiere desplegar la carcasa y nuevas rutas. El ajuste fino del acoplamiento es esencial en esta arquitectura.
para ti. Así que por eso me gusta modus operation. Aparte de eso, debes probarlo, es realmente bueno. Simplemente te permite componer tus React components en tiempo de ejecución en lugar de en tiempo de construcción. Y tiene muchas características con duplicación de dependencias, dependencias compartidas. Entonces, el siguiente paso es, bien, necesitamos elegir un router. Oh, he vuelto a decir router, porque root y route suenan igual. Pero estamos en Londres. Así que un router es la siguiente decisión que tenemos que tomar. Porque el router es la orquestación. ¿Qué vas a mostrar en la pantalla? Esta es una decisión muy importante cuando estás pasando de un monolito a microfrontends. Porque, ¿cómo vas a mostrar una aplicación u otra? Así que tengo tres opciones para ti. La primera es un router de nivel superior, que es básicamente solo un router normal. Solo piensa en el router de React en tu aplicación de una sola página. Es exactamente lo mismo. No hay diferencia. Estará haciendo toda la composición por ti. Todavía actúa como una sola aplicación y es básicamente solo un router de React. No hay mucha diferencia. La única diferencia es que esas aplicaciones se cargan en tiempo de ejecución en lugar de en tiempo de construcción. Los beneficios, bien, son simples, es lo mismo que has estado haciendo hasta ahora. Así que probablemente te resultará familiar con él. Es solo un router normal. Pero tenemos mucho acoplamiento allí. Y aquí es donde necesitas afinar cuánto acoplamiento vas a tolerar en tu nueva architecture. Así que el contexto es compartido. Es una sola aplicación de React. Tienes que desplegar la carcasa para desplegar nuevas rutas porque básicamente alguien tiene que decir cuáles son las rutas. Así que tienes
7. Multi-Router Distributivo
Short description:
Para mi caso de uso, me gusta la opción de compartir el contexto y desplegar mi aplicación shell. Otra opción es el multi-router distributivo, donde cada aplicación tiene su propio router y puede desplegar sus propias rutas de forma independiente. Sin embargo, este modelo es muy complejo y requiere comunicación entre los routers. Solo un router puede utilizar el historial del navegador, mientras que el resto utiliza el historial de memoria y métodos de sincronización. A pesar de la complejidad, este modelo ofrece un sistema completamente desacoplado.
para desplegar dos cosas, todavía hay acoplamiento. Así que este es bueno. Para mi caso de uso, me gusta este. No tengo problema con compartir el contexto y desplegar mi aplicación shell. Esto funciona para mí. Si esto no funciona para ti, entonces hay otra opción, que es lo que llamo el multi-router distributivo. Voy a estar cambiando de un lado a otro.
Así que este, la diferencia es que no hay un solo router. Hay varios. Así que el de arriba, React Router, sí, está bien. Y luego todos estos pueden ser 5, 4 o lo que quieras usar allí. Cada aplicación tendrá su propio router. Y esto es genial. Cada aplicación es su propia unidad. Básicamente pueden desplegar sus propias rutas como quieran. No tienen que depender de nadie más para definir y desplegar nuevas rutas. Y son realmente aplicaciones individuales de React. Hacen el renderizado de React por separado. Así que no están compartiendo nada, ni el árbol ni nada en absoluto. Son aplicaciones absolutamente completamente independientes. El problema que tengo con este modelo es que es muy complejo. No sé si alguien lo ha hecho en producción. Sé que hay mucho material por ahí. Es muy complejo. Necesitas comunicarte entre los routers. Solo un router tiene permiso para usar el historial del navegador. El resto tendrá que hacer un historial de memoria y un método de sincronización. Es muy complejo. Pero obtienes un sistema absolutamente 100% desacoplado. Así que si estás buscando absolutamente 100% no hay acoplamiento en absoluto, ni siquiera las instancias de React que se comparten, entonces esto
8. React Router y Contexto Compartido
Short description:
Si quiero algunas características de React Router 6, que son geniales, por cierto, no funcionarán porque no hay un contexto compartido. Para mi aplicación principal, tengo un router que es solo un router React normal, compartiendo un solo contexto y yo lo controlo. Pero hay una aplicación fuera de este contexto que necesita ser completamente separada. Puedes mezclarlos, pero hay cierto acoplamiento en algunas de las partes aquí.
es probablemente un modelo que podrías considerar. Pero también hay un par de advertencias. Si yo quiero algunas características de React Router 6, que son geniales, por cierto, no funcionarán porque no hay un contexto compartido. Y el último, el que he elegido para esta arquitectura, es, bueno, ¿qué tal una mezcla de ambos? Para mi aplicación principal tengo un router que es simplemente un router React normal, compartiendo un solo contexto y yo lo controlo. Pero hay una aplicación fuera de este contexto que necesita ser completamente separada. Hay otro equipo. La compañía adquirió una nueva startup y ellos están llegando, pueden usar un router separado. Puedes mezclarlos. Todavía tienes algunos beneficios, igual que el primero. Es a prueba de futuro. Si React Router desaparece, simplemente cámbialo. Compatible con versiones anteriores. Puedes usar React Router 3, 4, y React Router 6 o si estás en múltiples frameworks, que sabes que no soy muy fanático de. Pero esto es complejo. La comunicación sigue siendo difícil. Y hay cierto acoplamiento
9. Patrones Strangler y Reverse Strangler
Short description:
No podemos hacer una migración de golpe, así que usaremos el patrón Strangler o el patrón Reverse Strangler. El patrón Strangler implica reemplazar gradualmente partes del monolito con la nueva aplicación. El patrón Reverse Strangler implica poner todo el código del monolito en la nueva aplicación y eliminar gradualmente el código heredado. Los microfrontends buscan resolver problemas organizativos, no solo técnicos.
en algunas de las partes aquí. ¿Por qué no vas rápido? Correcto. Entonces, ¿cuál es la estrategia? ¿Cómo vamos a lograr esto? Ahora, lo único que está garantizado en una reescritura de golpe es un gran golpe. Así que no podemos hacer una migración de golpe. Y si estás tratando de hacer una migración de golpe, considera tus opciones. No lo recomiendo. ¿Cómo vamos a evitar la migración de golpe? Vale. Vamos a usar un patrón muy común. Se llama el patrón Strangler. He hablado de esto antes. Básicamente, tu monolito comenzará a cargar pequeños bits de la aplicación, la nueva aplicación, que están en azul aquí, hasta que los reemplaces todos. Y esto funciona. Me gusta el patrón Strangler. Es genial. Incluso puedes hacer widgets, como solo tienes en esta URL que el calculador financiero está bien. Es solo una nueva aplicación. Pero hoy te mostraré un enfoque diferente. El patrón Strangler es genial. ¿Sabes por qué es genial? Mucho mejor. Bueno, tal vez no mucho mejor, pero una opción es el patrón Reverse Strangler donde voy a poner todo el code que está en el monolito, todas las cosas que están ahí en mi nueva y brillante aplicación. Y voy a empezar a hacer algo que llamo encoger el monolito, que básicamente comienza a tomar esas piezas de code heredado y luego a eliminarlas, convirtiéndolas en una aplicación completamente nueva. Así que esto es lo que vamos a hacer. Esta es mi opción para esta recomendación de front-end monolítico 2.0, invirtiendo el encogimiento del monolito. Te dije que había dos partes. Ya sabes, la parte técnica, que discutí brevemente, y luego el plan organizativo. Los microfrontends están tratando de resolver un problema organizativo. Scaling, personas, equipos, etc. Así que no es solo técnico. No puedes simplemente ir a tus tomadores de decisiones y decir, está bien, vamos a usar todo esto, Composición,
10. Visión, Estrategia y Compromiso
Short description:
Al considerar los micro front-ends, es importante pensar en la visión y la estrategia. Establecer un sentido de urgencia para asegurar el compromiso. Involucrar a las personas enfatizando la visión compartida y estando abierto a nuevos enfoques. Las decisiones reversibles son cruciales debido a la naturaleza siempre cambiante de las cosas.
federación de módulos. De hecho, la mayoría de los problemas están en la organización. Así que las cosas en las que necesitas pensar son la visión y la estrategia. Entonces, ¿por qué queremos hacer esto? Por favor, asegúrate de hacer esta pregunta cada vez que estés pensando en micro front-ends. ¿Por qué estamos usando esto? ¿Qué estamos tratando de lograr? Y eso es la visión. Tu visión será ¿por qué necesitamos micro front-ends y por qué queremos usar micro front-ends? ¿Por qué nos va a dar eso? Así que esa es la visión. Y la estrategia es, está bien, ¿cómo vamos a hacer esto? ¿Cómo vamos a lograr esa visión de introducir micro front-ends a la organización? Así que eso es lo primero. Lo segundo es establecer un sentido de urgencia. Sabes, hagamos micro front-ends el próximo trimestre. Hagamos micro front-ends el próximo año. Sabes, hay un problema. Y he visto esto mucho. Hay un gran problema. Oh, todo está en llamas. Oh, creo que los micro front-ends serían buenos. Luego se apaga el fuego y todo vuelve a la normalidad y entonces, ya sabes, la idea sobre los micro front-ends probablemente está entre muchas ideas realmente buenas. Así que si estás llevando esto a tu organización, solo asegúrate de que dices, está bien, si vamos a hacerlo, necesitamos asegurarnos de que lo hacemos. Involucra a las personas. ¿Cómo convences a tu jefe o a tus líderes técnicos? Esa es una pregunta desafiante. Intenta involucrar a las personas. Intenta decir, está bien, estamos tratando de lograr la misma visión y podemos discrepar en cómo vamos a llegar allí. Eso está bien. Pero podemos simplemente intentar, ya sabes, ser amigos e involucrarlos. Y finalmente, estar abierto a nuevos enfoques. Las cosas cambian todo el tiempo y por eso es muy importante tener decisiones reversibles porque las cosas cambian todo el tiempo y necesitas estar abierto a cambiar tu decisión y asegurarte de que funciona para tu organización. Con eso, es solo el final. Esa es la conclusión de nuestro tiempo. Pero si tienes alguna pregunta, de nuevo, mi nombre es Ruben Casas. Si tienes alguna pregunta, sígueme en Twitter y envíame un mensaje. Estaré más que feliz de responder a ellas. Gracias.
This talk discusses the usage of Microfrontends in Remix and introduces the Tiny Frontend library. Kazoo, a used car buying platform, follows a domain-driven design approach and encountered issues with granular slicing. Tiny Frontend aims to solve the slicing problem and promotes type safety and compatibility of shared dependencies. The speaker demonstrates how Tiny Frontend works with server-side rendering and how Remix can consume and update components without redeploying the app. The talk also explores the usage of micro frontends and the future support for Webpack Module Federation in Remix.
Today's Talk discusses the importance of managing technical debt through refactoring practices, prioritization, and planning. Successful refactoring requires establishing guidelines, maintaining an inventory, and implementing a process. Celebrating success and ensuring resilience are key to building a strong refactoring culture. Visibility, support, and transparent communication are crucial for addressing technical debt effectively. The team's responsibilities, operating style, and availability should be transparent to product managers.
Debugging JavaScript is a crucial skill that is often overlooked in the industry. It is important to understand the problem, reproduce the issue, and identify the root cause. Having a variety of debugging tools and techniques, such as console methods and graphical debuggers, is beneficial. Replay is a time-traveling debugger for JavaScript that allows users to record and inspect bugs. It works with Redux, plain React, and even minified code with the help of source maps.
This Talk discusses building a voice-activated AI assistant using web APIs and JavaScript. It covers using the Web Speech API for speech recognition and the speech synthesis API for text to speech. The speaker demonstrates how to communicate with the Open AI API and handle the response. The Talk also explores enabling speech recognition and addressing the user. The speaker concludes by mentioning the possibility of creating a product out of the project and using Tauri for native desktop-like experiences.
This Talk discusses the importance of refactoring in software development and engineering. It introduces a framework called the three pillars of refactoring: practices, inventory, and process. The Talk emphasizes the need for clear practices, understanding of technical debt, and a well-defined process for successful refactoring. It also highlights the importance of visibility, reward, and resilience in the refactoring process. The Talk concludes by discussing the role of ownership, management, and prioritization in managing technical debt and refactoring efforts.
This Talk discusses various strategies to improve React performance, including lazy loading iframes, analyzing and optimizing bundles, fixing barrel exports and tree shaking, removing dead code, and caching expensive computations. The speaker shares their experience in identifying and addressing performance issues in a real-world application. They also highlight the importance of regularly auditing webpack and bundle analyzers, using tools like Knip to find unused code, and contributing improvements to open source libraries.
Construye Aplicaciones Modernas Utilizando GraphQL y Javascript
Featured Workshop
2 authors
Ven y aprende cómo puedes potenciar tus aplicaciones modernas y seguras utilizando GraphQL y Javascript. En este masterclass construiremos una API de GraphQL y demostraremos los beneficios del lenguaje de consulta para APIs y los casos de uso para los que es adecuado. Se requiere conocimiento básico de Javascript.
Construyendo una Aplicación de Shopify con React & Node
Top Content
WorkshopFree
2 authors
Los comerciantes de Shopify tienen un conjunto diverso de necesidades, y los desarrolladores tienen una oportunidad única para satisfacer esas necesidades construyendo aplicaciones. Construir una aplicación puede ser un trabajo duro, pero Shopify ha creado un conjunto de herramientas y recursos para ayudarte a construir una experiencia de aplicación sin problemas lo más rápido posible. Obtén experiencia práctica construyendo una aplicación integrada de Shopify utilizando el CLI de la aplicación Shopify, Polaris y Shopify App Bridge.Te mostraremos cómo crear una aplicación que acceda a la información de una tienda de desarrollo y pueda ejecutarse en tu entorno local.
¿Alguna vez has trabajado en una aplicación monolítica de Next.js? Yo sí, y escalar una gran aplicación de React para que muchos equipos puedan trabajar simultáneamente no es fácil. Con micro frontends, puedes dividir un monolito frontend en piezas más pequeñas para que cada equipo pueda construir e implementar de forma independiente. En este masterclass aprenderás cómo construir aplicaciones de React grandes que escalen utilizando micro frontends.
Las API/Backends son difíciles y necesitamos websockets. Utilizarás VS Code como tu editor, Parcel.js, Chakra-ui, React, React Icons y Appwrite. Al final de este masterclass, tendrás los conocimientos para construir una aplicación en tiempo real utilizando Appwrite y sin necesidad de desarrollar una API. ¡Sigue los pasos y tendrás una increíble aplicación de chat para presumir!
En Shopify a gran escala, resolvemos algunos problemas bastante difíciles. En este masterclass, cinco oradores diferentes describirán algunos de los desafíos que hemos enfrentado y cómo los hemos superado.
Tabla de contenidos: 1 - El infame problema "N+1": Jonathan Baker - Vamos a hablar sobre qué es, por qué es un problema y cómo Shopify lo maneja a gran escala en varios APIs de GraphQL. 2 - Contextualizando APIs de GraphQL: Alex Ackerman - Cómo y por qué decidimos usar directivas. Compartiré qué son las directivas, qué directivas están disponibles de forma predeterminada y cómo crear directivas personalizadas. 3 - Consultas de GraphQL más rápidas para clientes móviles: Theo Ben Hassen - A medida que tu aplicación móvil crece, también lo harán tus consultas de GraphQL. En esta charla, repasaré diversas estrategias para hacer que tus consultas sean más rápidas y efectivas. 4 - Construyendo el producto del futuro hoy: Greg MacWilliam - Cómo Shopify adopta las características futuras en el código actual. 5 - Gestión efectiva de APIs grandes: Rebecca Friedman - Tenemos miles de desarrolladores en Shopify. Veamos cómo estamos asegurando la calidad y consistencia de nuestras APIs de GraphQL con tantos colaboradores.
Descubre los Micro Frontends con Module Federation. Aprende sobre los beneficios y desafíos para que puedas decidir si los Micro Frontends son adecuados para tu organización.
Comments