Desde sua introdução no Radar em 2016, vimos uma ampla adoção de micro frontends para interfaces de usuário web. Recentemente, no entanto, observamos projetos estendendo esse estilo de arquitetura para incluir também micro frontends para aplicativos móveis. Quando um aplicativo se torna suficientemente grande e complexo, torna-se necessário distribuir o desenvolvimento entre vários times. Isso apresenta uma série de desafios em torno da autonomia do time, estruturas de repositório e frameworks de integração. No passado, mencionamos Atlas e BeeHive, mas esses frameworks não conseguiram ganhar força e não estão mais em desenvolvimento ativo. Abordagens mais recentes incluem Tuist ou Swift Package Manager para integrar o trabalho de vários times em um único aplicativo. Mas, em nossa experiência, os times geralmente acabam implementando seu próprio framework de integração. Embora definitivamente vejamos a necessidade de modularidade na ampliação dos times de desenvolvimento móvel, o caso dos micro frontends é menos certo. Isso porque enquanto os micro frontends implicam uma correspondência direta entre times e páginas ou componentes, essa estrutura pode acabar confundindo responsabilidades por contextos de domínio de negócio, aumentando assim a carga cognitiva do time. Nosso conselho é seguir o básico de um design de aplicativo bom e limpo, adotar a modularidade ao escalar para vários times e adotar uma arquitetura de micro frontend somente quando os módulos e o domínio de negócio estiverem fortemente alinhados.
Desde que os incluímos no Radar em 2016, vimos uma ampla adoção de micro frontends para interfaces de usuário web. Recentemente, entretanto, observamos projetos expandindo esse estilo arquitetural para também incluir micro frontends para aplicativos móveis. Quando o aplicativo se torna suficientemente grande e complexo, torna-se necessário distribuir o desenvolvimento entre vários times. Isso introduz o desafio de manter a autonomia dos times, ao mesmo tempo integrando seu trabalho em um único aplicativo. Alguns times escrevem seus próprios frameworks para habilitar esse estilo de desenvolvimento e, anteriormente, mencionamos Atlas e Beehive como possíveis formas de simplificar o problema de integração do desenvolvimento de aplicativos por múltiplos times. Mais recentemente, vimos times usando React Native para esse mesmo objetivo. Cada micro frontend React Native é mantido em seu próprio repositório, onde pode ser compilado, testado e implantado separadamente. A equipe responsável pelo aplicativo de forma geral pode, então, agregar esses micro frontends criados por diferentes times em um único release do aplicativo.
Desde que a introduzimos no Radar em 2016, vimos a adoção generalizada de micro frontends para UIs web. Recentemente, no entanto, temos visto projetos ampliando esse estilo arquitetural para incluir também micro frontends para aplicativos móveis. Quando o aplicativo se torna suficientemente grande e complexo, torna-se necessário distribuir o desenvolvimento entre vários times, introduzindo o desafio de manter a autonomia dos times enquanto integram seu trabalho em um único aplicativo. Embora tenhamos visto times criando seus próprias frameworks para permitir esse estilo de desenvolvimento, estruturas de modularização existentes como Atlas e Beehive também pode simplificar o problema de integrar o desenvolvimento de aplicativos por múltiplos times.
