En este nuevo artículo de #Ceibablog les presentaré una visión de alto nivel que les puede facilitar la toma de decisiones, bajo una reciente modalidad de desarrollo llamada microfrontends. Aquí resalto los aspectos que considero más importantes y qué debemos tener en cuenta cuando necesitemos implementar este concepto en algún proyecto o iniciativa.
Desde hace algunos años, se ha venido escuchando a nivel tecnológico acerca de la adopción generalizada de microfrontends para el desarrollo de interfaces web, incluso hoy en día, hemos visto proyectos que amplían este estilo arquitectónico para incluir también microfrontends en aplicaciones móviles. Estas nuevas tendencias implican una serie de desafíos en torno a la autonomía del equipo, las estructuras de los repositorios, los frameworks de integración, entre otros aspectos.
Como lo mencioné anteriormente, microfrontends es un estilo arquitectónico que podemos usar como una técnica para dividir proyectos en varios equipos, tendencia tecnológica que ha venido tomando auge en los últimos años. Aterricemos un poco más este concepto, a continuación:
- ¿Cómo ha sido la evolución que han tenido los proyectos software? Aplicaciones monolíticas: allí encontrábamos la aplicación como un todo.
- Backend y Frontend: notoria evolución que dividió el estilo monolítico, bajo esta modalidad surgieron principalmente equipos dedicados al Front-end, otros al Back-end e incluso algunos de DevOps.
- Microservicios: es muy frecuente encontrar proyectos con arquitecturas orientadas a microservicios dónde es muy común tener un solo Frontend y un Backend distribuido en varios microservicios.
Realmente, los microfrontends nacen porque los proyectos Front, en muchas ocasiones, se vuelven demasiado complejos y grandes, presentando inconvenientes de un enfoque monolítico, lo cual los hace difícil de mantener a través del tiempo. Empezamos a encontrar diferentes conflictos entre los equipos: conflictos a nivel de código, duplicidad de funcionalidades, conflictos de intereses; y manejamos una sola tecnología que, a veces, se vuelve dependiente. Incluso llegamos a tener dependencia en la entrega continua, ya que una funcionalidad puede llegar a depender totalmente de qué otras funcionalidades estén completas.
¿Qué estrategia podemos usar para dividir un frontend?
Microfrontends inicialmente propone una división del frontend, esta división se puede ver en algunos proyectos a nivel de bloques funcionales o segmentos de negocio; que pueden manejar una o varias tecnologías, incluso varios repositorios. Por ende, podemos concluir que son la representación técnica de un subdominio empresarial, que permiten una implementación independiente con la misma o diferentes tecnologías.
Una estrategia que podemos utilizar para dividir nuestra solución con este estilo, es usar el diseño estratégico con subdominios que plantea el enfoque de Domain Driven Design (DDD). Para esto, inicialmente debemos identificar, con la mayor claridad posible, el contexto general del problema a resolver.; lo podemos lograr apoyándonos en diagramas sencillos donde podamos mapear y analizar los objetivos, restricciones y riesgos naturales del negocio. La idea es tener como resultado un mapa general que nos dé visibilidad completa, una vez tengamos ese mapa del contexto general, debemos, con ayuda de los expertos del negocio, identificar los contextos más pequeños o subdominios.
Un subdominio es una parte lógica del dominio general. Nos ayuda a comprender un proyecto grande y complejo, identificando las partes encargadas de brindar soluciones puntuales a las áreas claves del negocio.
Ejemplo:
Esta técnica logra segmentar las responsabilidades de cada equipo, es decir, dividir los equipos en diferentes células de trabajo, dividir los pipelines y los repositorios, generando una clara independencia. Igualmente, nos ayuda a tener bloques simples y concretos pensados para un contexto de negocio, sin ninguna dependencia o acople, que genere inconvenientes, lo cual permite tener despliegues independientes, sus propios pipelines, equipos con buena autonomía y con gobierno sobre las aplicaciones que se estén desarrollando.
Técnicamente, podemos decir que este estilo arquitectónico propone varias microinterfaces y una aplicación contenedora (Shell). Algunos frameworks que podemos usar para trabajar son:
Metaframework: este es un single-spa.
iframes: elemento HTML que carga otra página o módulo HTML en la página padre.
Webcomponents: bloques de código que encapsulan la estructura de elementos HTML incluyendo CSS y JavaScript, permitiendo que el código pueda ser usado donde se requiera.
En algunos escenarios se genera cierta confusión respecto a componentes y microfrontends. No obstante, podemos decir que un componente es una solución técnica a un comportamiento específico que no tiene relación directa con requisitos propios o reglas de negocio de nuestro sistema y que puede ser controlado por un contenedor, por ejemplo: un botón, este puede cambiar características del contenedor, cambiar una etiqueta, modificar las propiedades de un campo de texto, cambiar colores de un elemento, etc. Ahora, un microfrontend, como bien lo hemos mencionado anteriormente, cambia ese enfoque dividiendo la aplicación en micro interfaces de usuario “específicas para el dominio” que se pueden desarrollar e implementar de forma independiente. Según esto, y dependiendo de las necesidades, es posible que podamos aplicar una de las dos técnicas o la combinación de ambas en un proyecto.
¿Qué debemos tener en cuenta para adoptar el estilo de microfrontends?
- Primero piensa en el diseño de la solución, orienta el diseño en la separación de responsabilidades y contextos de negocio bien definidos.
- Revisa todas aquellas dependencias que tenemos en el proyecto.
- Recuerda que microfrontends nace como una estrategia específica para proyectos grandes, en el que interactúan muchas personas, con un trabajo colaborativo continuo y amplio.
- Ten cuenta la madurez del equipo, esta debe ser alta para poder usarlo.
- Define y segmenta estos equipos con base en modelos de negocio, buscando un nivel adecuado de experiencia y conocimientos.
¿Cuándo no deberíamos usar este enfoque?
1. Si el equipo de desarrollo es pequeño:
Si el equipo es de tres a cinco personas no debería usarse, no es recomendable porque realmente no explotaría en mayor medida sus capacidades de independencia de equipos multifuncionales.
2. Cuando el equipo de desarrollo es inexperto en este estilo arquitectónico:
Debemos tener claridad que con este enfoque aumentan los retos de cara al flujo de peticiones en la interacción de los microfrontend y a su vez los retos de rendimiento operacional. Por este motivo recomendamos hacer pruebas de concepto evaluando los pro y contra de optar por este enfoque.
3. Si la aplicación está funcionando correctamente como un monolito:
Esto quiere decir que no es necesario, es decir, monolito no significa que sea malo, siempre y cuando, se tengan buenas prácticas y una arquitectura bien definida que el equipo asegure por diferentes medios.
4. Si previamente se tiene una buena estrategia de pipelines, un buen proceso de integración y despliegue continuo:
Si por alguna razón los microfrontends afectan los tiempos de entrega o hacen más complejo el proceso de desarrollo, no debería usarse, ya que claramente agregan complejidad al ciclo de vida del proyecto.
5. Cuando no se tenga claramente una estrategia de separación o delimitación de los dominios de negocio
6. Si el tamaño del proyecto es pequeño y su estrategia de reutilización es mínima.
Nota: No podemos aplicar este patrón de arquitectura solo por moda, como cualquier otro patrón, este soluciona problemas específicos y emplearlo solo por tendencia traería más problemas que ventajas.
Espero que este artículo haya sido útil para comprender los conceptos básicos de microfrontends. Sin embargo, este es solo el comienzo, ya que hay mucho más por aprender sobre este fascinante tema.
En la segunda parte de este blog, 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. ¡No se pierda la segunda parte de este #CeibaBlog!
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:
- https://github.com/rajasegar/awesome-micro-frontends
- https://martinfowler.com/articles/micro-frontends.html
- https://micro-frontends.org/
- Domain Driven Design Destilado – Vaughn Vernon (2016)
- https://dev.to/infoxicator/what-are-micro-frontends-really-2j2a
- https://www.enmilocalfunciona.io/microfrontends-y-modulos-federados/
- https://lucamezzalira.com/category/micro-frontends/
Excelente artículo, espero el 2do pronto.