Smashing Podcast Episodio 6 con Luca Mezzalira: ¿Qué son los micro-frontends?

¡Terminamos este año con otro podcast de Smashing! Esta vez, hablaremos de micro-frontends. ¿Qué es una micro-frontend? ¿En qué se diferencia del tipo de enfoque que podríamos estar adoptando en este momento? Descubrámoslo con el pionero de la micro-frontend, Luca Mezzalira.

Mostrar notas

Actualización semanal

• “Agregar funcionalidad dinámica y asíncrona a los sitios JAMstack”, Jason Lengstorf
• “Herramientas de datos cuantitativos para diseñadores de UX”, Adonis Raduca
• “Creación de habilidades de voz para Google Assistant y Amazon Alexa”, Tris Tolliday
• “Más allá del Sprint 0: una alternativa para integrar equipos”, Shamsi Brinn
• “Ayudando a los navegadores a optimizar con la propiedad CSS Contain”, Rachel Andrew

Micro-frontends

• Sitio web de Luca Mezzalira
• Lucas en Twitter
• “Micro-frontends, el futuro de las arquitecturas frontend” en Medium
• Se pueden encontrar más escritos de Luca sobre micro-frontends en su cuenta de Medium
• Libro de Luca “Arquitecturas Reactivas Front-End”

Transcripción

Drew McLellan: Es desarrollador de Google, experto en tecnologías web y administrador de la comunidad JavaScript de Londres. Con más de 15 años de experiencia, actualmente trabaja como vicepresidente de arquitectura, diseñando la plataforma de videos deportivos DAZN, que ofrece contenido deportivo a pedido a millones de usuarios que lo ven en vivo. Es el autor del libro Front-End Reactive Architectures para Apress y también es revisor técnico para Apress, Packt Publishing, Pragmatic Bookshelf y O'Reilly, además de ser un orador público experimentado en conferencias técnicas en todo el mundo. Es italiano, luce una hermosa barba y claramente tiene un profundo conocimiento de la plataforma web. Pero, ¿sabías que una vez cruzó Sudamérica en un avestruz? Mis grandes amigos, denle la bienvenida a Luca Mezzalira. Hola, Luca. ¿Cómo estás?

Luca Mezzalira: Estoy genial.

Drew: Quiero hablarles hoy sobre el tema de las micro-frontends. Este es un concepto que es completamente nuevo para mí, ciertamente por el nombre, y espero que también sea nuevo para muchos de nuestros oyentes. Antes de entrar en micro-frontends en sí mismos, supongo que deberíamos entender el problema que está buscando abordar con ellos. Entonces, tal vez podría contarnos un poco sobre cómo ve las aplicaciones de una manera más tradicional y qué tipo de problemas enfrentan esas cosas que quizás las micro-frontends podrían ser la solución.

Luca: Vale, en mi opinión es un buen punto de partida. Por lo general, cuando implementa o diseña un nuevo proyecto de campo verde y desea trabajar con aplicaciones front-end, tiene algunas arquitecturas que puede aprovechar. Puede usar una aplicación de una sola página, puede usar una aplicación de representación del lado del servidor o puede usar una aplicación de varias páginas compuesta simplemente por páginas HTML simples. Obviamente, esas son opciones súper válidas y creo que muy utilizadas por muchos, muchos desarrolladores. El verdadero problema que estamos tratando de resolver aquí es cómo puede escalar estos conceptos con equipos distribuidos a cientos de desarrolladores que trabajan en la misma base de código, porque la realidad es que cuando trabaja en estas plataformas en particular, cuando piensa en La plataforma SaaS, por ejemplo, necesita tener múltiples desarrolladores y múltiples equipos que estén trabajando en el mismo proyecto. Y, obviamente, la forma en que, por ejemplo, haces la adquisición o la retención es completamente diferente a la forma en que expones el catálogo o cómo muestras una parte específica de una plataforma.

Luca: Ahora, según mi experiencia, trabajo mucho con aplicaciones de una sola página. Trabajo con una aplicación de renderizado del lado del servidor, pero en algún momento de DAZN me pedirían que pensara en una forma de escalar nuestro equipo técnico. Y tengo que pensar... si para el back-end tenemos alguna solución que son microservicios en este caso, podemos escalar nuestras API de forma independiente y tener en cuenta la escala y el volumen para un rendimiento específico en una API específica. En la parte delantera, en realidad, es realmente más difícil porque si piensas en eso, no tienes un problema técnico que resolver cuando necesitas escalar, si estás usando una aplicación de una sola página, por ejemplo. Probablemente, para una representación del lado del servidor, tenga algunos, pero en una aplicación de una sola página, por ejemplo, se distribuye por naturaleza porque está en el lado del cliente, en un lado del cliente diferente.

Luca: Entonces, lo único que están cargando son solo algunos archivos estáticos como CSS, HTML y JavaScript que son servidos por CDN, y en ese caso puedes escalar en consecuencia, no es un gran desafío. Pero el verdadero desafío es cómo escalar los equipos que trabajan en la misma plataforma, porque a veces los desafíos que enfrenta un equipo pueden ser completamente diferentes de los desafíos que enfrenta otro equipo y, por lo general, lo que hace es tratar de encontrar una gran cantidad de compensaciones entre las cosas. Porque si piensas, intentemos pensar en un caso de uso normal. Por lo general, cuando comienzas una plataforma, comienzas poco a poco. Así que intenta crear esa aplicación rápida de una sola página, también tiene su monolito, por lo que simplemente configura todo en su CICD solo una vez para el front-end y el back-end, y luego comienza a iterar en su lógica. Pero la realidad es que cuando tienes éxito, necesitas evolucionar esta parte, y no siempre es mantener la misma arquitectura lo que podría, digamos, crear el beneficio para tu negocio, porque tal vez puedas encontrar algunos cuellos de botella.

Luca: Volvamos ahora a la parte de la aplicación de una sola página. Entonces, si queremos escalar una parte de una aplicación de una sola página, el desafío no es técnico, es con humanos si lo desea. Entonces, ¿cómo podemos escalar equipos que trabajan en la misma aplicación? Entonces, lo que hice hace unos años fue comenzar a buscar una posible arquitectura y principios que me permitirían escalar tanto el front-end como el back-end. Entonces, trabaje en los principios de back-end para que pueda encontrar los microservicios. Empecé a mirar la solución diferente y salieron con los micro-frontends que al principio ni siquiera los llamábamos así porque obviamente hace años no había, digamos, ese nombre para esa arquitectura específica. .

Luca: Pero la realidad es tomar un monolito, una aplicación de una sola página y cortarla de una manera que nos permita enfocarnos en un pequeño problema. Entonces, un problema más pequeño que toda la aplicación e intentar resolverlo de la mejor manera posible. Tecnicamente hablando. Obviamente, eso lleva a tener partes independientes de su aplicación frontend que podrían implementarse en producción sin afectar a todos los demás. Entonces, el desafío básicamente para Micro-frontend es tratar de encontrar la manera de tomar una aplicación de una sola página o una aplicación renderizada del lado del servidor y crear un artefacto de estos, digamos, lo más cerca posible de un dominio comercial, y puede implementarse de forma independiente. .

Drew: Me refiero a que mencionaste los microservicios en el back-end. Entonces, conceptualmente, este es un tipo similar de solución al problema. Los microservicios sirven en el back-end, pero se transfieren al front-end. ¿Es una equivalencia aproximada o está más involucrado en eso?

luca: si No, es una forma de resolver el mismo problema que intentan resolver los microservicios en el back-end pero en el front-end en este momento. Por lo general, cuando comencé este viaje al principio, ya sabes, comienzas a pensar en eso y comienzas a evaluar diferentes enfoques. Y en los últimos meses se me ocurrió lo que ellos llaman, el marco de decisión de Micro-frontend que básicamente son cuatro pasos que usan para, digamos, identificar un enfoque para Micro-frontend, porque si hasta ahora, por lo general, elegimos un marco que diseñó la arquitectura para nosotros y lo implementamos sobre su arquitectura. Si piensas en angular o piensas en React o Redux. Tienes todas las piezas que se necesitan pero no tomas decisiones arquitectónicas. Tomaría decisiones de diseño o cómo implementaría sobre esa arquitectura específica.

Luca: Entonces, en Micro-frontend necesitas comenzar el paso atrás. Entonces, primero debemos pensar en cómo queremos dividir nuestra aplicación. Entonces, generalmente hay dos opciones para eso. Puede segmentar horizontalmente, por lo que puede tener múltiples micro-frontends en la misma vista o puede segmentar verticalmente. Por lo tanto, siempre carga una Micro-frontend por vez. Y esas decisiones son bastante clave porque luego pondrán en cascada otras opciones que tiene en función de la decisión inicial que debe tomar. Así que lo primero, como dije, tú decides cómo quieres dividir tu aplicación. El segundo es cómo desea componer su aplicación. Por lo tanto, desea tener, por ejemplo, un shell de aplicación que cargue uno o varios micro-frontends en la misma vista. Desea tener, no sé, un servidor de aplicaciones que esté componiendo diferentes fragmentos de sus aplicaciones, por lo tanto, Micro-frontend diferente y luego sirva la vista final a su usuario. O desea usar el lado del borde incluido, es un estándar que está dentro de los CDN para componer una página y servirlos allí.

Luca: Esas son tres de las opciones que tienes. Y luego, además de componer, debes pensar cómo quieres enrutar. Entonces, cómo enruta desde, no sé, /login o /signin a la parte del catálogo o un objeto de detalle específico. También aquí tienes como tres opciones. Puede hacerlo en el servidor de aplicaciones, puede hacerlo en el nivel de CDN con Lambda Edge o cualquier otro trabajador web en CloudFlare o cualquier otra cosa. O puede hacer un sitio de cliente. Por lo tanto, tiene una lógica dentro del shell de su aplicación que dice, está bien, ahora para esta URL específica necesita cargar otra vista u otra micro-interfaz. Y lo último es cómo te comunicas con Micro-frontend.

Luca: Por lo general, si tiene varios Micro-frontend en la misma página, hay una mayor complejidad en la gestión de esta comunicación, porque necesita mantener los diferentes Micro-frontend independientes. Eso significa que no puede tener ninguna referencia sobre cómo está estructurada la página. Por lo general, puede usar cosas como eventos personalizados o un medidor de eventos que se inyecta dentro de cada Micro-frontend individual. Y luego el Micro-frontend se comunican juntos. Obviamente, en el otro caso, cuando tiene, digamos, una división vertical de su Micro-frontend es mucho más fácil, porque dentro de la vertical, básicamente, la representación de un Micro-frontend vertical es una aplicación de una sola página o una sola página. Y en ese caso, es más fácil, digamos, crear y compartir con un estado compartido en todo el Micro-frontend.

Luca: Entonces, si piensas en tener varios Micro-frontend juntos, debes evitar tener estados que se compartan en Micro-frontend, porque de lo contrario estás acoplando cosas. En lugar de todo el concepto, aquí se trata de desacoplar y tener un despliegue independiente. Y, por lo tanto, digamos que los desafíos de una división horizontal, que es la primera decisión que debe tomar o una división vertical, son completamente diferentes, y debemos ser muy conscientes de cuál se adapta a nuestro caso de uso.

Drew: Entonces, en lugar de una solución técnica específica, las microfrontends son más como un patrón de diseño que implementarías en cualquier tecnología que sea apropiada para el problema particular que estás tratando de resolver.

Luca: Sí, más que tecnología, me gustaría que elijamos la arquitectura correcta para el trabajo correcto. Solo para darle un ejemplo, estaba hablando... hay un marco famoso, bastante nuevo para Micro-frontend, se llama Luigi framework, que fue lanzado por SAP de código abierto. Lo que están haciendo es crear algunos iframes en los que envuelven su Micro-frontend dentro. Entonces, si piensa en eso, digamos, usando iframes hoy en día, está en un sitio web público que tal vez como el SEO u otras características que son obligatorias, podría ser problemático.

Luca: Pero en el caso de SAP, si piensas en eso, tienen una aplicación empresarial donde pueden controlar el navegador que usa el usuario, pueden controlar el entorno, no necesitan estar disponibles en una multitud o versión diferente del navegador. Entonces, para ellos, esto les permite tener ciertas áreas de la aplicación que son constantes y tienen ciertas áreas que cambian de forma independiente sin ningún problema. Pero, obviamente, una solución iframe no funcionaría en otra situación. Solo para dar otro ejemplo, Spotify, estamos usando iframes al principio. De hecho, la publicación de escritorio todavía está compuesta por múltiples iframes y cada iframe es una pequeña aplicación que hace, no sé, solo un reproductor de música o solo su recomendación, lo que sea. Intentan tener el mismo enfoque en la web, pero lo descartaron este año para volver a una aplicación de una sola página.

Luca: Y eso significa que explican por qué en el blog técnico, decían que, obviamente, si aplicas eso a millones de usuarios que usan iframes, necesitan cargarse cada vez que el mismo archivo de proveedores. Y luego tiene muchas dependencias duplicadas y el tiempo para interactuar con su página sería más largo. Entonces, en realidad, este enfoque podría adaptarse a ciertos casos de uso, pero no deberían adaptarse a todos. Es por eso que digo, como describí antes, si tiene un marco de decisión que lo ayuda a abordar esas cosas y puede comenzar a decir, está bien, dividí la aplicación de esta manera, por lo tanto, tengo esas opciones que están disponibles. cuando quiero componer, cuando quiero enrutar, cuando quiero comunicar, debe guiarte para tomar la decisión correcta en el momento adecuado.

Luca: Entonces, obviamente, aparte de esas cuatro decisiones, hay muchas otras. Por ejemplo, cómo crea consistencia en el sistema de diseño que tiene en todo el Micro-frontend. O no sé cómo manejas las dependencias y evitas el choque de dependencias dentro de la Micro-frontend, pero la realidad es que esas cuatro decisiones que mencioné antes te permitirán luego tomar todas las demás de una manera rápida sin tener que el problema de pensar demasiado, que es la mejor solución porque ya pones la piedra angular, los cuatro pilares, que te permitirán tomar todas las demás decisiones… no digo de una manera fácil, pero de una manera más rápida que un repaso o el espectro de oportunidades.

Drew: Mencionaste antes, la forma en que Micro-frontend puede ayudar con el tipo de estructura de equipos dentro de tu organización y tener muchas personas trabajando en la misma aplicación. ¿Cuáles son algunas de las implicaciones entonces y hace alguna diferencia si sus equipos están distribuidos o coubicados o si hay algún desafío que se enfrente allí?

luca: si Entonces puedo contarles cuál es la historia de DAZN. Esa es la empresa en la que estoy trabajando. Actualmente en DAZN, teníamos un lindo desafío. Así que actualmente tenemos más de 300 personas trabajando en la parte delantera y trasera de nuestra plataforma. Es una plataforma OTT que se transmite en vivo en eventos deportivos a nivel mundial. Y lo interesante es si todos los microservicios los sabemos gestionar más o menos y tenemos equipos distribuidos. Así que tenemos cuatro centros de desarrollo. Queríamos poner equipos en cada uno de los centros de desarrollo en el frente, y probamos este enfoque y funcionó bastante bien. Entonces, con Micro-frontend pudimos proporcionar diferentes dominios comerciales en diferentes ubicaciones y permitir la comunicación cruzada entre equipos dentro de un dominio comercial específico, porque en el peor de los casos, si tiene que hablar con otro equipo en su mismo dominio comercial , solo alcanzas la distancia a pie desde tu escritorio. Si, en cambio, necesita discutir algo específico en el equipo de distribución, tal vez con alguien en Londres en lugar de Amsterdam, o en lugar de una empresa en Polonia, simplemente organice una llamada.

Luca: Pero ese tipo de comunicación es más raro que los que ocurren entre equipos dentro de la misma ubicación. Y es por eso que empezamos a trabajar en eso. Entonces, lo primero que hicieron fue ver cómo nuestros usuarios interactuaban con nuestro sitio web, cómo estaba estructurada la empresa. Y cuando identifiquemos las cuatro áreas clave en las que estamos trabajando, que actualmente son la adquisición y la retención, digamos portar su aplicación central a múltiples televisores y dispositivos móviles y tener el dominio central que para nosotros es el reproductor de video y la fase de descubrimiento de nuestro contenido. Y finalmente todos los elementos de back office. Pude identificar esas cuatro áreas y nosotros esas cuatro áreas que asignamos para cada centro de desarrollo individual.

Luca: Obviamente, hay algún punto de contacto entre esas áreas, pero luego hay formas en las que puede, digamos, mitigar y tener un taller inicial con los diferentes equipos que están en diferentes ubicaciones y luego trabajar para lograr el mismo contrato de API, por ejemplo, o el mismo objetivo con tener algunos puntos de control durante el desarrollo. Pero lo bueno de acercarse que permitió acercarse con Micro-frontend es el hecho de que finalmente entendemos profundamente cómo funcionaba nuestro sistema. Nos sentamos y analizamos cómo estábamos estructurados y cambiamos no solo la forma en que afectábamos las cosas, sino también cómo funcionaba la empresa. Y ese fue un tipo de enfoque diferente de lo que han visto hasta ahora. Pero está demostrando que funciona bastante bien en el caso de que cada equipo individual pueda interactuar con el equipo de la misma ubicación en el mismo dominio.

Luca: Así que están hablando exactamente en el mismo idioma si estás hablando del diseño basado en el dominio. Y es que si necesitan interactuar con otros equipos, literalmente pueden compartir el taller o volar a otro centro de desarrollo y es menos que un problema. Pero de esta manera, digamos, aumentamos el rendimiento y reducimos la sobrecarga de comunicación, y el alcance de las dependencias que estaban ocurriendo en otra situación en la que estaban trabajando.

Drew: ¿Y todos estos equipos deben usar como un marco de JavaScript estandarizado? ¿Todos deben codificar en las mismas cosas, todos deben ser React o Angular o permitir la interoperabilidad entre ellos o las personas pueden usar diferentes cosas para diferentes Micro-frontend?

luca: si Así que en DAZN decidimos cortar verticalmente nuestra Micro-frontend y esa fue una decisión que nos permitió tener la libertad de elegir la tecnología que necesitamos para cada Micro-frontend. Teniendo en cuenta que cada vez que cargamos una Micro-frontend por vez, esto significa que, por ejemplo, la forma en que tenemos una página de destino es diferente del proceso de inicio de sesión/registro. Para que podamos actualizar... estamos usando principalmente React en este momento. Pero si, por ejemplo, recuerdo cuando React 16 era un lanzamiento que pudimos lanzar en producción React 16, también si no estaba en la versión estable solo para una página de destino y ver si funcionaba sin afectar todo el otros equipos

Luca: Y luego, a su propio ritmo, a su propio ritmo, estaban actualizando sus propias cosas. Eso nos permite también, digamos, probar nuevas tecnologías o nuevas suposiciones que tenemos sobre la aplicación existente con una cierta cantidad de usuarios. Porque implementamos las versiones candidatas también para front-end. Implementamos, digamos, varias prácticas que nos permiten probar ciertos momentos en la producción y ver cómo funcionan las cosas.

Luca: La belleza de estos enfoques es que podemos decidir de forma independiente tener la herramienta correcta para el trabajo correcto más que tener un denominador común en toda la pila. Porque como puedes imaginar, cuando comenzaste a trabajar en un proyecto, la decisión que tomaste los primeros años probablemente sea diferente a la decisión que tomaste en una trayectoria donde la empresa está creciendo, el negocio está evolucionando y estos se volvieron más maduros. y el desafío es completamente diferente. Entonces no sería lo suficientemente flexible o ágil, si piensas en eso, el hecho de que sigamos con la misma decisión que tomamos hace dos años. En particular una institución como DAZN, que pasamos básicamente de cero a 3000 empleados en tres años. Entonces, como puede imaginar, fue un crecimiento masivo y fue un crecimiento masivo para la empresa, así como para la base de usuarios.

Drew: ¿Existe una forma establecida para que las diferentes micro-frontend compartan datos y se comuniquen entre sí, por ejemplo, solo para mantenerse al día con la misma vista o hay una forma de hacerlo?

Luca: Sí, lo hay. Depende de cuál sea el marco de decisión, qué camino vas a tomar. Porque si vas a tomar el corte vertical, eso se volvió muy fácil. Entonces, lo que tenemos para comunicarnos a través de Micro-frontend es un shell de aplicación que se carga en Micro-frontend dentro de sí mismo. Y lo que hace es almacenar todo lo que tiene que ser, digamos, compartido entre diferentes Micro-frontend o en un almacenamiento web, ya sea una sesión o almacenamiento local o en memoria. Y luego, en función de esa información, se carga el Micro-frontend, se puede recuperar desde el shell de la aplicación a esta información y luego consumirla, modificarla o cambiarla. Depende completamente de cómo divida la aplicación, pero en este caso, solo para proporcionar un ejemplo, si piensa que cuando son usuarios autenticados y necesitan ir a la página de inicio de sesión, cuando ingresan y las API se consumen y están proporcionando un token JWT, Micro-frontend los está pasando al shell de la aplicación y el shell de la aplicación comienza a guardar su almacenamiento web.

Luca: Luego, después de eso, el shell de la aplicación carga la nueva área autenticada para esa aplicación específica y esas áreas autenticadas, recuperan el token JWT del shell de la aplicación y realizan un token de acceso de actualización o validan algunos datos que comienzan dentro del ficha JWT. Así que está usando básicamente la información que fue producida por otro Micro-frontend en su propia rueda.

Drew: Suena como un concepto muy interesante y puedo ver potencialmente muchas grandes ventajas en trabajar de esta manera, pero seguramente no puede estar exento de desafíos. ¿Hay alguna cosa en particular con la que sea más difícil lidiar cuando se diseñan las cosas de esta manera?

Luca: Creo que, ante todo, los principales desafíos que veo son el cambio de mentalidad. Porque antes estábamos acostumbrados a tener, digamos, los líderes tecnológicos o los desarrolladores líderes que decidían todo en torno a una aplicación completa y tomaban todas las decisiones. Ahora finalmente pasamos de esta entidad centralizada a una entidad descentralizada que es local para cada estado. Como pueden imaginar, esto trae algunos desafíos porque si antes teníamos a alguien que estaba trazando el camino, ahora tenemos, digamos, varias personas en la parte superior definiendo el camino correcto dentro de su dominio, y esto es un gran cambio. de mentalidad

Luca: Por otro lado, creo que la complejidad es aceptar a veces que hacer la abstracción incorrecta podría ser, digamos, más costoso que duplicar el código. Y es que sé que hay algo que encontré muy desafiante en la gestión de desarrolladores porque están pensando: "Bien, ahora puedo reutilizar este objeto o esta biblioteca específica cientos de veces dentro del proyecto", pero la realidad es muy diferente. Vi una biblioteca de componentes que era abstracta y dedicaron mucho tiempo a convertirlo en el mejor código de la historia o el mejor en una forma perfecta. Pero la realidad se usó solo dos veces. Así que el esfuerzo de hacer eso, no fue exactamente eso. Vi en las bibliotecas del otro lado que comenzaron con un par de casos de uso para un componente específico. Y luego esos casos de uso se convirtieron en 10 y luego el código se volvió imposible de mantener.

Luca: Entonces, tratar de agregar una nueva función dentro del mismo componente podría ser más un riesgo que un beneficio. Entonces, creo que la otra cosa que debemos entender con Micro-frontend es cuánto queremos compartirlo y cuánto queremos duplicar. Y no hay daño, honestamente, duplicando. En nuestro caso, por ejemplo, tenemos una duplicación de pie de página y encabezado, y lo hicimos principalmente porque cambiamos como tres veces el encabezado en cuatro años. Entonces, como puede imaginar, el hecho de que estemos centralizando estos, se asignen a un equipo y creen una dependencia externa para todos los equipos, todos los cientos de desarrolladores que tenemos, es más, digamos, un problema que un beneficio para la empresa porque no estamos agregando un valor enorme.

Luca: Al mismo tiempo, actualmente estamos refactorizando, nuestras bibliotecas compartidas que serían bibliotecas de pago, porque obviamente el pago tiene alguna lógica detrás de eso y si queremos cambiar una vez, no queremos aplicar eso dos veces en múltiples partes del código. Queremos tener solo una biblioteca que sea una fuente de verdad, pero para el encabezado y el pie de página, también si hay una discrepancia o para el píxel o si hay una función que se implementa como una semana después, no dañará el solicitud.

Drew: Entonces, ¿hay algunas señales reveladoras que las personas deberían buscar al evaluar una aplicación y pensar: "Oh, sí, este sería un buen candidato para pasar a una arquitectura tipo Micro-frontend?"

Luca: Sí, por lo que mi sugerencia sería, ante todo, que no comenzaría un proyecto nuevo con Micro-frontend a menos que sepamos exactamente cómo se debe construir. Y, por lo general, es muy poco probable que tenga esta información porque, particularmente si tiene una nueva plataforma o un nuevo proyecto y es la primera vez que trabaja en esto, podría ser una tarea fácil encontrar esta información. Por lo general, lo que sugiero es comenzar con una arquitectura existente que sería una aplicación de una sola página y luego evolucionarla. En particular, por ejemplo, encontré que creo que usar Micro-frontend para aplicaciones heredadas o cuando queremos reemplazar una parte específica de la aplicación o cuando tenemos un proyecto que queremos evolucionar y escalar para múltiples equipos, esos son tres casos de uso que siento muy fuerte podría adaptarse a la arquitectura Micro-frontend. Obviamente, eso no significa que a partir de ahora todo deba hacerse Micro-frontend, porque Micro-frontend no es la bala de plata en absoluto.

Luca: Lo que son es una arquitectura adicional que podemos aprovechar en el mundo frontal. Y hasta ahora teníamos como una cierta cantidad de arquitecturas, ahora tenemos una adicional. Pero eso es un montón de desafíos porque, obviamente, es necesario, si antes de la representación del lado del servidor o una aplicación de una sola página, hay patrones claros que fueron explorados y luego implementados por varios marcos, etc. Con Micro-frontend actualmente, es una forma de hacer las cosas. Pero agregar el marco de decisiones probablemente debería permitir que las personas tomen las decisiones correctas para sus casos de uso. Porque a menudo hay muchos conceptos erróneos sobre qué es Micro-frontend y cómo deben usarse. Y mucha gente está pensando que tal vez, digamos, son malos para, no sé, tener demasiadas bibliotecas en una vista u otras cosas.

Luca: La realidad es que necesitas entender profundamente el concepto, entender cómo implementarlo y luego puedes empezar a trabajar en eso. Estoy completamente de acuerdo en que existen desafíos técnicos y muchas decisiones que debe tomar y no puede comenzar de inmediato con un editor frente a usted escribiendo código y pensando, está bien, ahora estoy creando una micro-interfaz. arquitectura. Porque necesita comprender el concepto, comprender el contexto y crear, también gobernar en torno a eso porque la complejidad no es solo escribir el código, también es comprender cómo encajan todas las piezas en la parte CICD, la parte SEO y así sucesivamente.

Luca: Entonces, Micro-frontend proporciona, digamos, un nivel de flexibilidad y requiere mucho esfuerzo para definir el gobierno correcto. Porque cuando tienes el gobierno correcto, todo sería fluido. A menudo, y desafortunadamente diría que demasiado a menudo, vi empresas que no dedican suficiente tiempo al lado de la gobernanza, por ejemplo, a comprender la CICD, porque no creen que esto sea importante. Pero en cambio, para Micro-frontend, como para microservicios, tener la automatización adecuada le permitirá acelerar el desarrollo. Si no dedica suficiente tiempo a la parte de automatización, corre el riesgo de tener más carga que beneficios.

Drew: Supongo que es como muchas cosas en el mundo del desarrollo web donde las personas corren el peligro de sumergirse en una solución técnica antes de que hayan entendido realmente el problema. Y parece que con Micro-frontend es en gran medida un caso en el que necesita ver el problema y luego implementar la solución para saber qué problema está resolviendo. Supongo que la naturaleza misma de Micro-frontend hace que sea muy fácil comenzar a integrarse en una aplicación existente, detectar un pequeño problema e intercambiarlo con un Micro-frontend para resolver ese problema. ¿Es una sugerencia razonable?

Luca: Sí, yo diría que sí. En este caso, lo único que sugeriría si empezáramos de esta manera es mirar más el corte vertical sobre el corte horizontal, porque de lo contrario necesita resolver tantos problemas, supongamos que, por ejemplo, está usando Angular y desea pasar a una nueva versión de Angular. Si necesita tener dos versiones de Angular viviendo juntas sin usar I-frame, podría ser complicado o incluso imposible. Entonces, si comienzas, no miras el aspecto desde … si revisas el desafío, no desde el punto de vista técnico, sino desde el punto de vista comercial. Tal vez, por ejemplo, puede tomar, no sé, la parte de inicio de sesión en la que desea escribir con una versión diferente o la misma versión pero con una versión más actualizada de un marco y esa podría ser una buena manera. Y luego vas por el camino. Esa podría ser una buena manera de reemplazar lenta pero constantemente una aplicación específica.

Luca: Lo que hemos hecho en nuestro caso es básicamente aplicar el patrón de estrangulador que es un patrón muy conocido para microservicios, pero en la parte delantera. Entonces, según la URL y según el navegador y el país del usuario. De manera lenta pero constante, básicamente estábamos acabando con el monolito, que en este caso era una aplicación de una sola página, lanzando nuestra nueva aplicación con más frecuencia y viendo los comportamientos de los usuarios, si estaba mejorando la experiencia, estaba causando algún problema en nuestro sistema. O no. Y eso nos permitió brindar valor inmediato al negocio, pero al mismo tiempo nos permitió probar nuestras suposiciones y ver si íbamos en la dirección correcta o no.

Drew: Suena como una solución muy atractiva para algunos problemas que estoy seguro que mucha gente está enfrentando. Si yo, como desarrollador, quisiera comenzar a investigar más sobre Micro-frontend, ¿dónde sería un buen lugar para comenzar?

Luca: Sí, actualmente paso mucho de mi tiempo libre tratando de abogar por esta arquitectura, porque creo que hay muchos conceptos erróneos. En mi cuenta de Medium. He escrito varios artículos que también están disponibles allí. Un montón de videos grabados en conferencias que puedes encontrar en YouTube sin ningún problema. Y la otra cosa que sugeriría si está buscando algún ejemplo de código en algunos marcos, el que recomendaría para comenzar es un solo SPA, principalmente porque tiene un enfoque de corte vertical, es más fácil recogerlo y puede comenzar a comprender el beneficio de esta arquitectura. Luego hay muchos otros que están disponibles. Before I mentioned Luigi framework, as well as many others that are currently out there that are allowing you to compose multiple Micro-frontends in the same view.

Luca: Like another one in my head is TailorJS is another interesting. But definitely there is open components that is one developed by Open Table. But in general there are plenty of opportunity if you start to search about Micro-frontend, they're out there.

Drew: That sounds great. Is there anything else that you wanted to talk about with regard to the Micro-frontends?

Luca: Yeah. Personally I would suggest to take an open mind approach on learning this architecture and this approach, technical approach, mainly because I believe that there is a lot of good, but we need to, let's say, invest a bit of time and spend a bit of time to deeply understand how the things are working. Because obviously there isn't, just one way to do things. We are used that we take a framework and immediately we start to work on it and it's super productive, if you think about that.

Luca: But in this case you need to spend a bit of more time understanding, as you said a couple of times, the problem. Understand which is the pattern that would allow you to express better not only from a technical point of view but those two from our organizational point of view, the solution that you have in mind.

Drew: So I've been learning all about Micro-frontend today. What have you been learning about lately?

Luca: Recently there are two things that I'm learning. So last week I was in Las Vegas during the AWS event and is obviously a cloud conference. Pretty amazing, 70,000 people, a lot of sessions that were spreading several hotels in Vegas. And there for me, a serverless is a paradigm that I'm studying the most because I truly believe that in the future that will be the way how we are going to design and implement software and obviously AWS is very prominent on this approach.

Luca: And the second topic is around management and how to be a leader of a tech team. Because obviously I'm SVP of architecture. I have a team of architects that I'm leading and you can never rest because you need to not only to be on top of the technical side, but you need also to understand the people problems, understand how you can make them successful. Because obviously if they are successful, you are successful. You are first a technical facilitator to a certain extent. So that for me, those for me are the two things that currently I'm studying on top of exploring the Micro-frontend world.

Drew: If you, dear listener, would like to hear more from Luca, you can follow him on Twitter where he's @LucaMezzalira or find his activities collected together at Lucamezzalira.com. Thanks for joining us today, Luca. Did you have any parting words?

Luca: No, but thank you very much for listening up to now.