Código redundante enviado pelo canal com Micro-frontends

Meu entendimento sobre os micro-frontends é que o principal problema que eles resolvem é ajudar as empresas a ter várias equipes possíveis e diferentes, trabalhar em componentes / aplicativos pequenos que serão usados ​​para compor um aplicativo da Web grande.

Aqui, o principal problema que está sendo resolvido é a capacidade de várias equipes trabalharem independentemente e ainda serem capazes de construir um grande composto. O problema NÃO é ter um pacote de liberação enxuta para o usuário final . Esse entendimento está correto?

É verdade que, se tivermos vários aplicativos pequenos sendo usados ​​para compor um aplicativo Web grande, poderemos ter vários aplicativos pequenos enviando a mesma biblioteca Javascript ( como o Lodash ) para os navegadores dos usuários finais como parte de suas pacotes de fornecedores individuais levando a uma certa quantidade de código duplicado / redundante sendo enviado ao usuário?

Não é uma preocupação que devemos nos preocupar ao arquitetar o aplicativo front-end?

Você está absolutamente certo de que há uma troca envolvida aqui: você está negociando alguns aspectos da experiência do usuário para obter uma melhor experiência do desenvolvedor (o que, por sua vez, pode melhorar a experiência do usuário de maneiras diferentes). Isso vale a pena? Depende.

Por exemplo, eu acho que o Spotify usa essa abordagem para dividir sua interface do usuário em componentes isolados ( fonte ). Cada widget vive em um iframe e, portanto, pode ter seu próprio conjunto de bibliotecas, etc. Eles têm a restrição organizacional exclusiva de que o trabalho é realizado por esquadrões autônomos (uma equipe multifuncional). Isso torna mais difícil concordar com os padrões de toda a empresa e depois alterá-los. Portanto, para eles, as micro-interfaces ajudam a preservar alguma flexibilidade. Mas, sem essa abordagem, talvez o aplicativo para desktop seja menos prejudicial à memória.

O cache HTTP não vai ajudar muito: cada micro-front-end pode usar diferentes versões da estrutura. Além disso, o custo da duplicação não é apenas a transferência de dados, mas os custos do cliente de (re) compilar as bibliotecas e armazenar estruturas de dados duplicadas.

Pessoalmente, acho que essas micro-interfaces podem ser uma arquitetura válida, mas provavelmente desaconselháveis, a menos

• você é uma organização muito grande, com equipes altamente autônomas, que trabalham na interface do usuário e precisam fazer lançamentos muito frequentes (por exemplo, diariamente) e
• seu orçamento de desempenho do UX tem espaço para essa duplicação ou seu produto é tão bom que o UX não importa. Observe que o desempenho deve ser testado em dispositivos low-end, não em sua máquina de desenvolvimento.

Se sua organização não é grande ou se suas equipes são um pouco mais especializadas, pode ser mais fácil para todos os envolvidos (gerenciamento, desenvolvedores e, finalmente, usuários) ter um processo comum de criação e implantação que evita duplicação desnecessária. Por exemplo, se você tiver apenas quatro equipes trabalhando na interface do usuário, elas provavelmente poderão conversar entre si para concordar com um conjunto comum de bibliotecas e como integrar seu trabalho em uma arquitetura coesa.

Os micro-frontend parecem ser uma dessas coisas realmente legais, mas que você não precisa até operar em escala.