Desde que se introdujeron en el Radar en 2016, hemos visto la adopción generalizada de micro frontends para las interfaces web. Recientemente, sin embargo, hemos visto proyectos que amplían este estilo arquitectónico para incluir también micro frontends para aplicaciones móviles. Cuando una aplicación se vuelve lo suficientemente grande y compleja, es necesario distribuir el desarrollo entre varios equipos. Esto presenta una serie de desafíos en torno a la autonomía del equipo, las estructuras de los repositorios y los frameworks de integración. En el pasado hemos mencionado Atlas y BeeHive, pero estos marcos no lograron ganar tracción y ya no están en desarrollo activo. Otros enfoques más recientes son Tuist o el Swift Package Manager para integrar el trabajo de varios equipos en una sola aplicación. Pero, según nuestra experiencia, los equipos suelen acabar implementando su propio framework para la integración. Mientras que definitivamente vemos la necesidad de la modularidad en la ampliación de los equipos de desarrollo móvil, el caso de los micro frontends es menos seguro. Esto se debe a que, mientras que los micro frontends implican una correspondencia directa entre los equipos y las páginas o los componentes, esta estructura podría acabar desdibujando las responsabilidades de los contextos del dominio empresarial, aumentando así la carga cognitiva del equipo. Nuestro consejo es seguir los fundamentos de un diseño de aplicación correcto y limpio, abrazar la modularidad cuando se amplíe a varios equipos y adoptar una arquitectura de micro frontend sólo cuando los módulos y el dominio de negocio esten fuertemente alineados.
Desde su introducción en el Radar de 2016, hemos visto una amplia adopción de los micro frontends para interfaces de usuario (UIs) web. Sin embargo, recientemente, hemos visto proyectos que extienden este estilo de arquitectura para incluir también micro frontends para aplicaciones móviles. Cuando la aplicación se vuelve suficientemente grande y compleja, es necesario distribuir su desarrollo entre múltiples equipos. Esto presenta el reto de mantener la autonomía de dichos equipos, mientras se integra su trabajo en una única aplicación. Algunos equipos escriben sus propios frameworks para habilitar este estilo de desarrollo, y, en el pasado, hemos mencionado a Atlas and Beehive como posibles maneras de simplificar el problema de integrar el desarrollo de apps en múltiples equipos. Más recientemente, hemos visto a equipos utilizando React Native para lograr lo mismo. Cada micro frontend de React Native se mantiene en su propio repositorio, donde puede ser compilado, probado y desplegado por separado. El equipo responsable de la aplicación completa puede después consolidar todos estos micro frontends, desarrollados por diferentes equipos, en una sola aplicación terminada.
Desde su introducción en el Radar en 2016, hemos visto una adopción generalizada de micro frontends para interfaces de usuario web. Recientemente, hemos visto proyectos que amplían este estilo arquitectónico para incluir también micro frontends para aplicaciones móviles. Cuando la aplicación se vuelve lo suficientemente grande y compleja, se hace necesario distribuir el desarrollo entre múltiples equipos. Esto presenta el desafío de mantener la autonomía del equipo mientras se integra su trabajo en una sola aplicación. Aunque hemos visto equipos que escriben sus propios frameworks para habilitar este estilo de desarrollo, los frameworks de modularización existentes como Atlas y Beehive también pueden simplificar el problema de integrar el desarrollo de aplicaciones con múltiples eq
