De Monolito a Micro-Frontends

Rate this content
Bookmark

Muchas empresas en todo el mundo están considerando adoptar Micro-Frontends para mejorar la agilidad y escala del negocio, sin embargo, hay muchas incógnitas cuando se trata de cómo se ve el camino de migración en la práctica. En esta charla, discutiré los pasos necesarios para migrar con éxito una aplicación monolítica de React hacia una arquitectura de frontend más modular y desacoplada.

22 min
21 Oct, 2022

Video Summary and Transcription

Los Micro-Frontends se consideran 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 micro-frontends implica desacoplar el sistema y explorar opciones como un monolito modular. Los Micro-Frontends permiten implementaciones independientes y composición en tiempo de ejecución, pero existe 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. El patrón de Estrangulador y el patrón de Estrangulador inverso se utilizan para reemplazar gradualmente partes del monolito con la nueva aplicación.

Available in English

1. Introducción a los Microfrontends

Short description:

Vamos a hablar sobre cómo transformar monolitos en microfrontends. React ha estado aquí por mucho tiempo y las aplicaciones que ahora son un poco antiguas comienzan a crecer y romperse. Los problemas suelen estar relacionados con la organización y las complicaciones que surgen con el crecimiento. El crecimiento exponencial, la duplicación de código y la falta de claridad en la propiedad son algunos de los problemas. Muchas personas y empresas consideran los microfrontends como una solución.

Entonces, mi nombre es Ruben y soy un ingeniero senior en Postman. Y el tema de hoy es interesante. Vamos a hablar sobre cómo transformar monolitos en microfrontends. Ahora, este es nuestro evento de React, ¿verdad? Bueno, React ha estado aquí por mucho tiempo, ¿verdad? ¿El próximo año, React cumplirá cuántos años? Diez años, ¿verdad? Entonces, los reclutadores probablemente dirán: `Finalmente, vamos a pedir diez años de experiencia en React`. React ha estado aquí por mucho tiempo. Si tienes aplicaciones que ahora son un poco antiguas. Bueno, técnicamente, no viejas, viejas, pero en el esquema general de la tecnología, probablemente están envejeciendo. Y el problema con eso es que las aplicaciones se vuelven antiguas y comienzan a crecer y crecer. Y ¿cuál es el problema con el crecimiento? Bueno, probablemente comience a romperse en algún momento. Y probablemente lo estemos experimentando. Ahora, si piensas, si has estado trabajando con React, piensa en los problemas que tienes ahora mismo, probablemente tendrás una larga sesión de personas quejándose de los problemas que tienes. Pero en su mayoría no se trata de React en sí, generalmente se trata de la organización. Se trata de cómo, a medida que tu empresa y la aplicación crecen, las cosas comienzan a complicarse y dificultarse para escalar. Entonces, comienzas a tener problemas como el crecimiento exponencial, como tener muchas líneas de código. Tienes más desarrolladores, sabes, cuando comenzaste ese proyecto solo eran dos o tres. Ahora tienes muchos grupos de desarrolladores, especialmente para empresas bastante grandes. La integración continua tarda mucho en completarse. Todos odiamos eso. Queremos que las cosas sean rápidas. Duplicación de código. No hay una propiedad clara. ¿Quién es dueño de qué? Etcétera, etcétera. Entonces, tenemos muchos problemas. Ese gráfico de dependencias es el peor. Lo odio. Tenemos muchas dependencias y no sabemos de dónde vienen ni qué está usando qué. Entonces, hay muchos problemas. Probablemente estés familiarizado con esto. Todos estos problemas han llevado a muchas personas a pensar en los microfrontends. ¿Deberíamos usar microfrontends para resolver este problema? Y muchas personas y empresas

2. Transición de Monolitos a Microfrontends

Short description:

¿Cómo pasamos de un monolito a microfrontends? El objetivo principal de pasar de un monolito a microfrontends es eliminar el acoplamiento y el acoplamiento accidental. Las personas quieren ir a microfrontends, pero no entienden por qué. Si quieres ir a una arquitectura distribuida, si quieres resolver esos problemas que tienes con la escalabilidad de una gran aplicación monolítica, primero debes desacoplarla.

muchas personas 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?

De acuerdo. 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. Me voy a enfocar un poco más en cómo llegar allí, en lugar de qué son. Y puedo tocar un par de conceptos. Pero ese es el objetivo principal de esta... En realidad, te voy a decir 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 hacer que te veas bien. Cuando vayas a la próxima reunión, ¿verdad, si quieres impresionar a todos en esa sala, ¿verdad?, te 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. De inmediato. Eso te hará sonar como la persona más inteligente de esa sala. Entonces, desacoplar las piezas, y eso es Ryan Florence, por cierto. Gran cita. No soy yo. El acoplamiento es un gran problema. Y, de hecho, lo peor que el acoplamiento es el acoplamiento accidental. Eso es lo peor de todo. Entonces, el objetivo principal, bueno, no de esta charla, pero el objetivo principal de pasar del monolito a 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 que se me ocurrió. Las personas quieren ir a microfrontends, pero no entienden por qué. Y esta es una razón lo suficientemente buena. Si quieres ir a una arquitectura distribuida, si quieres, ya sabes, resolver esos problemas que tienes con la escalabilidad de una gran aplicación monolítica, primero debes desacoplarla.

3. Decoupling and the Modular Monolith

Short description:

Antes de aplicar microfrontends, comencemos con el desacoplamiento del sistema. Los microfrontends tienen como objetivo desacoplar el monolito y dar sentido al grafo 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 que cuando comenzaste. Y en realidad, tengo una charla sobre los riesgos de adoptar microfrontends cuando realmente no los necesitas. Así que antes de aplicar microfrontends, debemos comenzar con el desacoplamiento del sistema. ¿Y qué es el acoplamiento? Bueno, hay muchos tipos diferentes de acoplamiento. Pero si comienzas a notar que las cosas comienzan a cambiar juntas, ya sabes, como el código que cambia junto se mantiene unido, pero si ese código se mantiene unido, comienzas a tener muchas dependencias entrelazadas y las cosas comienzan a ser realmente difíciles de implementar de forma independiente o de tener una idea de cómo es el sistema. Entonces, antes de pasar a distribuir el sistema, antes de pasar a microfrontends, creo que si hacemos nuestro objetivo desacoplar nuestras bases de código, eso sería un objetivo logrado. Así que, solo recuerda, desacoplamiento. Ese es el objetivo principal. El objetivo principal de los microfrontends es desacoplar el monolito. Tratar de dar sentido a ese grafo 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. Nuevamente, los microfrontends son una de ellas. Pero, hoy, solo te desafiaré. Por favor, intenta todas las otras opciones.

No vayas y digas, OK, los microfrontends son la solución. Hay muchas soluciones. Yo ideé un gráfico, como un diagrama, que llamé el espectro desacoplado y distribuido, que es un lugar largo donde puedes ir de uno al siguiente hasta resolver tu problema. Explicaré brevemente este gráfico. Entonces, tenemos el monolito, ¿verdad? Ahí es donde estamos ahora mismo. Algunas personas tienen el monolito con backend y frontend todavía. Pero supongamos que no tenemos eso. Supongamos que backend ya está dividido en microservicios. Todavía tenemos el monolito y la aplicación frontend en el monolito. Estamos luchando porque no podemos implementar, es muy difícil, todos estos problemas que discutimos brevemente. Si paso directamente a los microfrontends y no he explorado todos los pasos intermedios, simplemente llego a esta conclusión que puede que no sea la solución para mi problema. Solo recuerda, uno de los principales problemas es el desacoplamiento. ¿Cómo nos desacoplamos? Vamos paso a paso. Intentemos un monolito modular. Este enfoque también es muy 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 del equipo y límites dentro de una aplicación monolítica, pero aún tienen acoplamiento y no se pueden implementar de forma independiente. Las aplicaciones integradas ofrecen más flexibilidad, pero aún se implementan como una unidad única. Los microfrontends permiten implementaciones independientes y composición en tiempo de ejecución, lo que permite implementaciones separadas de unidades individuales. Sin embargo, las implementaciones independientes no siempre son la mejor solución, y hay una charla después de esta que discute la alternativa de mantener una aplicación integrada compuesta en tiempo de ejecución. Ahora, centrémonos en cómo hacer la transición de un monolito a microfrontends con un plan de acción.

Aún es un monolito, se implementa como una unidad única, pero tienen cierta propiedad del equipo, tienen ciertos límites, pueden dar sentido a la aplicación un poco mejor y aún tienen cierto acoplamiento, por lo que aún estamos en la escala de acoplamiento en lugar de la escala desacoplada, pero no se pueden implementar de forma independiente. Eso es una de las cosas principales de los monolitos modulares, tienes que implementar todo, y aún tienes mucho acoplamiento en su interior, por lo que toda la interfaz de usuario y las bibliotecas y todo está ahí. Pero para tu empresa, para tu caso de uso, un monolito modular podría ser perfectamente válido y podría funcionar y resolver muchos de tus problemas. Así que, échale un vistazo si quieres. Mira un monolito modular. Y luego el siguiente paso es, ¿qué tal las aplicaciones integradas? Las aplicaciones integradas son un poco más flexibles que un monolito modular. Hay muchos enfoques y muchas herramientas de monorepo que intentan ayudarte con una aplicación integrada, que básicamente significa que tienes múltiples aplicaciones aún dentro de una base de código. Podría ser un monorepo. Y se implementan y componen en tiempo de compilación. Así que, aún no puedes implementar de forma independiente. Aún puedes implementar, pero una vez que lanzas la aplicación, esto es clave, se lanza como esa única unidad todavía. Así que esa es la diferencia principal. Ahora, finalmente hemos llegado a los microfrontends. Entonces, ¿qué obtienes si aplicas microfrontends? Si no te detienes en las aplicaciones integradas y monorepos. Y la clave son las implementaciones independientes. Así que, tendrás implementaciones independientes y composición en tiempo de ejecución con microfrontends, lo que significa que no tienes que implementar esa única unidad nuevamente de una vez. Puedes implementar esas unidades independientes por separado. Y eso podría ser lo que necesitas. O tal vez no sea lo que necesitas. ¿Correcto? Así que, podría ser que las implementaciones independientes realmente causen 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 implementaciones independientes. ¿Qué pasa si simplemente mantenemos una aplicación integrada que está compuesta solo 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 microfrontend. Hemos decidido que necesitamos microfrontends. Necesitamos implementaciones independientes. ¿Cómo lo hacemos? Correcto. Necesitamos un plan de acción. Y este plan de acción consta de 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 implementando de forma independiente y componiendo cosas, necesitas encontrar un modelo de composición. Para una aplicación de una sola página de React, la representación del lado del cliente con la operación de modus de Webpack es una buena elección. La operación de modus permite flexibilidad y decisiones reversibles, evitando invertir en la tecnología equivocada.

Necesitamos un plan técnico y organizativo. Y espero poder explicar el técnico. Y al final, hablaremos del organizativo. Entonces, lo primero es, si estás implementando de forma independiente y estás componiendo cosas, necesitas encontrar cómo lo vas a hacer, 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. Así que imaginemos que tenemos una aplicación de React. Solo para simplificar, es una aplicación de una sola página. No se representa en el lado del servidor. Voy a elegir un modelo de composición basado en la representación del lado del cliente y voy a utilizar la operación de modus de Webpack, que es una gran herramienta y te diré por qué me gusta tanto. Pero, básicamente, lo vamos a mantener simple. La composición en el lado del servidor es posible. Solo es 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 bueno para usar con la operación de modus de Webpack. Te dije por qué iba a decir por qué me gusta la operación de modus. Una cosa importante y es muy flexible. Y una cosa importante en este viaje de monolito a microtransparencia, es asegurarte de tomar decisiones reversibles. Que hagas la transición gradualmente. La operación de modus te permite tener esa flexibilidad. Porque estoy importando un módulo externo usando la operación de modus, 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 la operación de modus no es lo mío y no funciona para mí, bueno, es muy fácil volver a la composición en tiempo de compilación y cargar desde MPM en lugar de desde la operación de modus. Entonces, tomar decisiones reversibles es muy, muy importante. Porque no quieres embarcarte en un viaje de, nuevamente, ir a microfrontends y darte 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 Enrutador para Microfrontends

Short description:

La operación de modus te permite componer componentes de React en tiempo de ejecución en lugar de tiempo de compilación. La elección de un enrutador es una decisión crucial al pasar de un monolito a microfrontends. Hay tres opciones: un enrutador de nivel superior, un enrutador de subaplicación y un enrutador de microfrontend. El enrutador de nivel superior es similar a un enrutador normal, pero tiene más acoplamiento y requiere implementar la carcasa y las nuevas rutas. Ajustar el acoplamiento es esencial en esta arquitectura.

para ti. Por eso me gusta la operación de modus. Aparte de eso, es bueno revisarlo, es realmente bueno. Simplemente te permite componer tus componentes de React en tiempo de ejecución en lugar de tiempo de compilación. Y tiene muchas características con duplicación de dependencias, dependencias compartidas. Entonces, el siguiente paso es, ¿verdad?, necesitamos elegir un enrutador. Oh, he vuelto a decir enrutador, porque raíz y ruta suenan igual. Pero estamos en Londres. Entonces, el enrutador es la siguiente decisión que tenemos que tomar. Porque el enrutador es la orquestación. ¿Qué vas a mostrar en la pantalla? Esta es una decisión muy importante cuando pasas 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 enrutador de nivel superior, que básicamente es solo un enrutador normal. Solo piensa en el enrutador 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. Aún actúa como una sola aplicación y básicamente es solo el enrutador de react. No hay muchas diferencias. La única diferencia es que esas aplicaciones se cargan en tiempo de ejecución en lugar de tiempo de compilación. Los beneficios, bueno, son los mismos que has estado utilizando hasta ahora. Así que probablemente te resultará familiar. Es solo un enrutador normal. Pero hay mucho acoplamiento allí. Y aquí es donde necesitas ajustar cuánto acoplamiento vas a tolerar en tu nueva arquitectura. Entonces, el contexto es compartido. Es una aplicación de react. Debes implementar la carcasa para implementar nuevas rutas porque alguien tiene que decir cuáles son las rutas. Entonces tienes

7. Distributive Multi-Router

Short description:

Para mi caso de uso, me gusta la opción de compartir contexto e implementar mi aplicación principal. Otra opción es el distributive multi-router, donde cada aplicación tiene su propio enrutador y puede implementar sus propias rutas de forma independiente. Sin embargo, este modelo es muy complejo y requiere comunicación entre los enrutadores. Solo un enrutador 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 implementar dos cosas, aún hay acoplamiento. Así que este es bueno. Para mi caso de uso, me gusta este. No tengo problema con compartir contexto e implementar mi aplicación principal. Esto funciona para mí. Si esto no funciona para ti, entonces hay otra opción, que es lo que llamo el distributive multi-router. Voy a estar alternando entre ellos.

Entonces, en este caso, la diferencia es que no hay un solo enrutador. Hay varios. Así que el principal, React Router, sí, está bien. Y luego todos estos pueden ser 5, 4 o cualquier número que quieras usar allí. Cada aplicación tendrá su propio enrutador. Y esto es genial. Cada aplicación es su propia unidad. Básicamente pueden implementar sus propias rutas como deseen. No tienen que depender de nadie más para definir e implementar nuevas rutas. Y en realidad son aplicaciones individuales de React. Hacen React en render por separado. Así que no están compartiendo nada, ni el árbol ni nada en absoluto. Son aplicaciones absolutamente independientes. El problema que tengo con este modelo es que es muy complejo. No sé si alguien lo ha utilizado en producción. Sé que hay mucho material al respecto. Es muy complejo. Necesitas comunicarte entre los enrutadores. Solo se permite que un enrutador utilice el historial del navegador. El resto tendrá que utilizar el historial de memoria y el método de sincronización. Es muy complejo. Pero obtienes un sistema completamente desacoplado al 100%. Así que si estás buscando un 100% sin 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 enrutador que es simplemente un enrutador normal de React, compartiendo un contexto y yo lo controlo. Pero hay una aplicación fuera de este contexto que necesita estar completamente separada. Puedes combinarlas, pero hay cierto acoplamiento en algunas partes aquí.

es probablemente un modelo que podrías considerar. Pero también tiene algunas advertencias. Si 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 combinación de ambos? Para mi aplicación principal tengo un enrutador que es simplemente un enrutador normal de React, compartiendo un contexto y yo lo controlo. Pero hay una aplicación fuera de este contexto que necesita estar completamente separada. Hay otro equipo. La empresa adquirió una nueva startup y se están uniendo, pueden usar un enrutador separado. Puedes combinarlos. Aún tienes algunos beneficios, igual que en el primero. Es a prueba de futuro. Si React Router desaparece, simplemente cámbialo. Compatible hacia atrás. Puedes usar React Router 3, 4 y React Router 6 o si te gustan múltiples frameworks, lo cual sabes que no soy muy fanático. 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 utilizaremos 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 tienen como objetivo 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 golpe de golpe. Por lo tanto, no podemos hacer una migración de golpe de golpe. Y si estás intentando hacer una migración de golpe de golpe, considera tus opciones. No lo recomiendo. ¿Cómo vamos a evitar la migración de golpe de golpe? Bien. Vamos a utilizar un patrón muy común. Se llama el patrón Strangler. Ya he hablado de esto antes. Básicamente, tu monolito comenzará a cargar pequeñas partes de la aplicación, la nueva aplicación, que están en azul aquí, hasta que las reemplaces todas. Y esto funciona. Me gusta el patrón Strangler. Es genial. Incluso puedes hacer widgets, como simplemente tienes en esta URL que la calculadora financiera 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 código que está en el monolito, todo lo que está ahí dentro, en mi nueva y reluciente aplicación. Y voy a empezar a hacer algo que llamo reducir el monolito, que básicamente consiste en tomar esas piezas de código heredado y luego eliminarlas, convirtiéndolas en una nueva aplicación. Así que esto es lo que vamos a hacer. Esta es mi opción para esta recomendación de la versión 2.0 del monolito en el front-end, revertir el reducir el monolito. Te dije que había dos partes. Ya sabes, la parte técnica, que discutí brevemente, y luego el plan organizativo. Los microfrontends intentan resolver un problema organizativo. Escalabilidad, personas, equipos, etc. Así que no es solo técnico. No puedes simplemente ir a tus tomadores de decisiones y decir, okay, vamos a usar todo esto, Composición.

10. Visión, Estrategia y Compromiso

Short description:

Al considerar micro front-ends, es importante pensar en la visión y la estrategia. Establecer un sentido de urgencia para garantizar el compromiso. Involucrar a las personas enfatizando la visión compartida y estar 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. Entonces, las cosas en las que necesitas pensar son la visión y la estrategia. Entonces, ¿por qué queremos hacer esto? Asegúrate de hacer esta pregunta cada vez que pienses en micro front-ends. ¿Por qué estamos usando esto? ¿Qué estamos tratando de lograr? Esa es la visión. Tu visión será ¿por qué necesitamos micro front-ends y por qué queremos usar micro front-ends? ¿Qué nos va a dar eso? Esa es la visión. Y la estrategia es, bien, ¿cómo vamos a hacer esto? ¿Cómo vamos a lograr esa visión de introducir micro front-ends en la organización? 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 muchas veces. Hay un gran problema. Oh, todo está en llamas. Oh, creo que los micro front-ends serían buenos. Luego el fuego se apaga y todo vuelve a la normalidad y luego, ya sabes, la idea de los micro front-ends probablemente esté entre muchas ideas realmente buenas. Entonces, si estás presentando esto a tu organización, asegúrate de decir, okay, si lo vamos a hacer, necesitamos asegurarnos de hacerlo. Involucra a las personas. ¿Cómo convences a tu jefe o a tus líderes técnicos? Esa es una pregunta desafiante. Trata de involucrar a las personas. Trata de decir, okay, estamos tratando de lograr la misma visión y podemos estar en desacuerdo sobre cómo vamos a llegar allí. Eso está bien. Pero podemos 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 funcione para tu organización. Con eso, es el final. Esa es la conclusión de nuestro tiempo. Pero si tienes alguna pregunta, nuevamente, mi nombre es Ruben Casas. Si tienes alguna pregunta, sígueme en Twitter y envíame un mensaje. Estaré encantado de responder a ellas. Gracias.

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

Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

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.
React Day Berlin 2022React Day Berlin 2022
29 min
Fighting Technical Debt With Continuous Refactoring
Top Content
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt. In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.
React Advanced Conference 2023React Advanced Conference 2023
22 min
Power Fixing React Performance Woes
Next.js and other wrapping React frameworks provide great power in building larger applications. But with great power comes great performance responsibility - and if you don’t pay attention, it’s easy to add multiple seconds of loading penalty on all of your pages. Eek! Let’s walk through a case study of how a few hours of performance debugging improved both load and parse times for the Centered app by several hundred percent each. We’ll learn not just why those performance problems happen, but how to diagnose and fix them. Hooray, performance! ⚡️

Workshops on related topic

React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
Top Content
WorkshopFree
Shopify merchants have a diverse set of needs, and developers have a unique opportunity to meet those needs building apps. Building an app can be tough work but Shopify has created a set of tools and resources to help you build out a seamless app experience as quickly as possible. Get hands on experience building an embedded Shopify app using the Shopify App CLI, Polaris and Shopify App Bridge.We’ll show you how to create an app that accesses information from a development store and can run in your local environment.
JSNation Live 2021JSNation Live 2021
113 min
Micro Frontends with Module Federation and React
Workshop
Did you ever work in a monolithic Next.js app? I did and scaling a large React app so that many teams can work simultaneously is not easy. With micro frontends you can break up a frontend monolith into smaller pieces so that each team can build and deploy independently. In this workshop you'll learn how to build large React apps that scale using micro frontends.
JSNation 2022JSNation 2022
41 min
Build a chat room with Appwrite and React
WorkshopFree
API's/Backends are difficult and we need websockets. You will be using VS Code as your editor, Parcel.js, Chakra-ui, React, React Icons, and Appwrite. By the end of this workshop, you will have the knowledge to build a real-time app using Appwrite and zero API development. Follow along and you'll have an awesome chat app to show off!
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Hard GraphQL Problems at Shopify
WorkshopFree
At Shopify scale, we solve some pretty hard problems. In this workshop, five different speakers will outline some of the challenges we’ve faced, and how we’ve overcome them.

Table of contents:
1 - The infamous "N+1" problem: Jonathan Baker - Let's talk about what it is, why it is a problem, and how Shopify handles it at scale across several GraphQL APIs.
2 - Contextualizing GraphQL APIs: Alex Ackerman - How and why we decided to use directives. I’ll share what directives are, which directives are available out of the box, and how to create custom directives.
3 - Faster GraphQL queries for mobile clients: Theo Ben Hassen - As your mobile app grows, so will your GraphQL queries. In this talk, I will go over diverse strategies to make your queries faster and more effective.
4 - Building tomorrow’s product today: Greg MacWilliam - How Shopify adopts future features in today’s code.
5 - Managing large APIs effectively: Rebecca Friedman - We have thousands of developers at Shopify. Let’s take a look at how we’re ensuring the quality and consistency of our GraphQL APIs with so many contributors.
JSNation 2023JSNation 2023
57 min
0 To Auth In An Hour For Your JavaScript App
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.js backend + Vanilla JS frontend) to authenticate users with One Time Passwords (email) and OAuth, including:
- User authentication – Managing user interactions, returning session / refresh JWTs- Session management and validation – Storing the session securely for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.