Cómo comenzar, desafíos y antipatrones

En esta segunda parte de este #CeibaBlog, profundizaremos en los desafíos a los que debemos enfrentar, cómo tener cuidado para no incurrir en algunos antipatrones y algunas conclusiones al implementar microfrontends.

En la primera parte de este artículo destacamos a los microfrontends como una técnica para dividir los proyectos front demasiado complejos y grandes en varias microinterfaces compuestas. Esto nos facilita la división de los equipos de trabajo, nos ayuda a segmentar las responsabilidades, a tener bloques simples y concretos pensados para un contexto de negocio específico.

Por otra parte, resaltamos algunas bondades relacionadas con la independencia y autonomía de trabajo e hicimos un repaso de la evolución de los proyectos software, desde el enfoque monolítico hasta los microservicios. Por último, resaltamos cómo plantear una división o solución bajo este estilo arquitectónico.

A continuación, centraremos nuestra atención en los desafíos a los que nos debemos enfrentar bajo este enfoque:

¿Cómo comenzar?

Si nuestro punto de partida es un sistema monolito, lo primero que debemos hacer es una tarea fuerte de refactor con el fin de empezar a modularizar la aplicación, es decir, debemos desacoplar el monolito. Esto lo podemos descomponer, delimitando capacidades empresariales, subdominios, por tipos de transacciones o por equipos.
Debemos tener claro lo que implica adoptar el concepto de microfrontend, en este punto proponemos arrancar con pruebas de concepto para lograr una perspectiva más cercana a la realidad respecto a cómo manejar temas relacionados con seguridad, autenticación, la orquestación de los componentes y elementos comunes. Aquí podemos identificar posibles riesgos o restricciones técnicas que deberíamos mitigar con alguna estrategia distinta.
Debemos tener en cuenta cómo vamos a organizar todo lo relacionado con los estilos que tendrá nuestra aplicación, ya que esto es vital para mantener estilos consistentes y evitar conflictos entre los equipos de trabajo. Es clave que en los proyectos se haga énfasis en los detalles de imagen corporativa compartida porque debe ser homogénea en cada microfrontend.

Equipos_horizontales_ceibablog

Los desafíos que debemos enfrentar

La madurez en prácticas técnicas del equipo:

Tenemos que conformar equipos con suficiente apertura en prácticas técnicas. La experiencia del equipo también es importante para esta nueva tendencia, nuestros equipos deben estar nivelados y gestionando adecuadamente el conocimiento a través de ellos.

La gestión del conocimiento de negocio para poder modularizar los componentes en este enfoque:

Con el fin de identificar y evaluar cómo evitar la duplicidad de código o de componentes. En caso tal, una buena opción sería definir una estrategia con enfoque en componentes comunes. Esta es una tarea que debemos hacer bien desde el principio, desde etapas tempranas e inception, es decir, previamente hicimos pruebas de concepto para tener claro cuál es el camino a seguir.

Implementar componentes en diferentes tecnologías:

Debemos revisar los costos que pueden impactar al proyecto y al equipo en general respecto a la curva de conocimiento, entendimiento y destreza en una o varias tecnologías. La experiencia del equipo de desarrollo debe ser alta, siempre y cuando, los microfrontends los desarrollemos en más de una tecnología, con el fin de mejorar también el proceso de desarrollo y resolver adecuadamente los desafíos técnicos que se nos presenten.

Es necesario dejar claro que en este orden de ideas podemos implementar microfrontends en varias tecnologías, algo que es clave, pero que no debemos considerar como una restricción obligatoria. Este es un tema clave que debemos discutir en la definición técnica que tendrá el proyecto, ya que sin duda será complejo que mantengamos varias tecnologías. Lo anterior puede llegar a ocasionar problemas de rendimiento y esto es muy importante en proyectos que tienen como driver de arquitectura este criterio.

Teniendo en cuenta todo lo anterior y entendiendo las necesidades de equipos altamente productivos, sugerimos manejar una sola tecnología. Si se usa una sola librería/framework podemos lograr un óptimo rendimiento. En caso de querer mejorar una aplicación o migrarla a otra librería, recomendamos hacerlo de manera gradual, poco a poco, hasta que los elementos y componentes que estén desarrollados en la librería inicial ya no existan. Una técnica muy usada en estos escenarios es el Strangler Pattern que básicamente propone una estrategia para migrar de manera gradual una aplicación.

Imagen de: https://www.it-labs.com/micro-frontends/

Tengamos cuidado con los siguientes antipatrones

Microfrontends vs. Componentes:

Frecuentemente caemos en el error de confundir estos conceptos, por esto es importante que tengamos claro sus diferencias y evitemos definir micro interfaces como componentes. Recordemos que los microfrontends representan subdominios del contexto general del negocio y, por lo tanto, esta debería ser nuestra hoja de ruta.

Multi tecnología:

Como lo mencionamos anteriormente, en este estilo arquitectónico tenemos la libertad de usar varias tecnologías. Sin embargo, el uso de estas puede llegar a generar diferentes retos e inconsistencias a nivel de experiencia de usuario, rendimiento y choques de dependencias entre ellas. Nuestra recomendación es, que en la medida de lo posible, orientemos estas implementaciones con una sola tecnología.

Infierno de dependencia:

Comúnmente, durante los desarrollos nos apoyamos en paquetes o bibliotecas compartidas de código para resolver alguna funcionalidad particular, y cuando instalamos estos paquetes nos regimos a una versión específica. Mientras nuestros proyectos evolucionan, es posible que nuestra aplicación genere incompatibilidad de versiones por algún cambio en nuestros paquetes compartidos. Normalmente, estas incompatibilidades se solucionan actualizando versiones de las dependencias; sin embargo, esto puede romper otras dependencias y llevar el problema a otro conjunto de paquetes, generando reprocesos en estabilización y complejizando el proceso de desarrollo. Asegurémonos y busquemos estrategias para que todos los microfrontends permanezcan alineados en las mismas versiones de nuestras bibliotecas compartidas.

Comunicación del estado global de la aplicación:

Evitemos usar un estado global para compartir información o comunicarse entre microfrontends. El principio básico de este estilo arquitectónico es que los microfrontends sean independientes, si utilizamos un estado compartido violamos este principio fundamental. Por esto, pensemos en eliminar los puntos únicos de falla, esto lo logramos planteando enfoques de comunicación a través de eventos.

Algunas conclusiones a las que podemos llegar son

Debemos establecer cuándo implementar una aplicación basada en componentes o microfrontends:

La clave estará en los contextos de negocio que servirán como guía para construir nuestra aplicación. El enfoque de aplicaciones basados en componentes o microfrontends es solo una forma de cómo implementar una solución. Recordemos que la ventaja de los microfrontends es la independencia de trabajo, de despliegues, de tecnologías y de probar responsabilidades bajo estas premisas.

Orientemos este tipo de enfoques bajo el concepto de Code Splitting:

Es decir, pensemos mucho en reutilización.

Evitemos manejar estados de la aplicación o librerías específicas:

La idea con esto es evitar dependencias. Podemos comunicar los microfrontends a través de mensajes o eventos; no sin antes resaltar, que la comunicación debe ser mínima, por esto, si tenemos componentes que están en constante comunicación de eventos, es muy probable llegar a pensar que no deberían estar separados. Las estrategias más comunes de comunicación entre microfrontends y microservicios son las Cookies y Http Only.

Los equipos no pueden ser 100% independientes, ni 100% autónomos:

Debe existir una figura o equipo que defina y orqueste la dinámica de trabajo. Con esto quiero hacer énfasis en que debe haber mucha sincronía y cohesión en los equipos.

Debe existir un sistema de diseño transversal:

Como única guía de diseño para evitar sobreponer estilos y ganar en la estandarización de estas prácticas.

Por último, pero no menos importante, la adopción de prácticas técnicas no es un aspecto negociable en esta forma de trabajar. Debemos contar con la sincronía de repositorios de código fuente, ambientes de integración continua, lineamientos de desarrollo, pruebas automatizadas que permitan a los equipos reaccionar tempranamente a los errores y que sean un pilar fundamental para garantizar la calidad de nuestro producto.

Si deseas implementar microfroentends en tus proyectos o tienes alguna necesidad de desarrollo web para tu negocio, puedes ponerte en contacto con nosotros o visitar nuestro servicio de Diseño y construcción de productos digitales.

Referencias

Microfrontends: cómo comenzar, desafíos y antipatrones