Microfronts em iframe
Em uma empresa, o CTO tomou uma decisão equilibrada e deliberada de que os microfronts devem ser iguais aos microsserviços e devem ser veiculados em iframes.
Como argumento, aliás, foi dado o produto Office 360 da Microsoft, anteriormente ele usava `<iframe />` para os menus superior e lateral. Agora, os iframes não estão lá.
Razões e pré-requisitos para microfronts
Uma das principais vantagens do microfront-ends é a divisão da funcionalidade do monólito em equipes, a capacidade de conduzir testes de ponta a ponta de forma mais granular e também torna mais fácil vender software em partes (no caso de soluções em caixa).
Todos os aplicativos disponíveis são React SPA. Eles não têm nada em comum, exceto Material UI, React Router v4 e o embryo UI-kit como módulos npm.
Alguns aplicativos serão usados e entregues em uma versão autônoma e como parte de outro aplicativo.
Microfronts foram divididos em grandes blocos funcionais:
- Cabeçalho do aplicativo. Roteamento entre aplicativos
- Aplicativo de painel. Com métricas e widgets. Cada widget do painel deve fazer parte do aplicativo correspondente (conectado por meio de um iframe).
- Os próprios aplicativos. Alguns deles incluem partes um do outro (mas sem fanatismo e recursão)
Assim, diferentes ciclos de liberação são obtidos, independentes uns dos outros. Desde que os aplicativos sigam a API interna.
Problema nº 0. Separação incorreta de microfronts
Infelizmente, os microfronts não foram pensados com profundidade suficiente. Um exemplo é uma loja online. O botão de compra e o carrinho de compras podem estar espalhados em muitos lugares, mas são todos uma microfronta. Como um cartão de produto em 10 variações, e o processo de encomenda (onde contas e endereços). Todos esses podem ser microfronts separados com seus próprios ciclos de lançamento.
Na realidade, descobriu-se que os aplicativos foram divididos de forma muito aproximada. Em analogia com uma loja online, isso ocorre quando uma equipe faz o carrinho e a página de checkout, e a segunda equipe faz o resto (incluindo contadores de carrinho em todas as outras páginas). Ao mesmo tempo, todos usam a mesma lógica de negócios e a interface é reutilizada no nível do kit de UI ou da biblioteca Material-UI.
Descobriu-se que os aplicativos funcionais (marcados em verde e roxo) têm muito em comum. Uma parte significativa da lógica de negócios nesses dois aplicativos teve que ser separada em uma microfront separada e usada. Na verdade, estão longe de ser duas dessas aplicações. No total, havia cerca de sete aplicativos funcionais que não reutilizam a lógica no nível adequado.
Como resultado, a economia de tempo na reutilização de aplicativos falhou. A duplicação de funcionalidade também permaneceu em alto nível. Usar microfront-end sem iframes ou componentes com lógica mais complexa do kit de UI estendido pode resolver o problema de duplicação de funcionalidade.
Problema nº 1. Falta de orquestração de processo
Enquanto muitas questões sobre a organização de microsserviços foram discutidas. Como eles vão se comunicar, por qual protocolo, a organização do processo de interação entre microfrontados foi colocado em segundo plano.
Para neutralizar todos os problemas do CORS de uma vez por todas, foi decidido implantar o nginx, que trataria do roteamento. Assim, cada microfront e cada microsserviço tinha seu próprio endereço, por exemplo: A questão permanece, como testar aplicativos durante o modo de desenvolvimento? Cada aplicativo será servido em uma porta diferente?
https://domain.zone/dashboard
https://domain.zone/header
https://domain.zone/app1
https://domain.zone/app2
https://domain.zone/api1
https://domain.zone/api2
É aqui que o pacote `http-proxy-middleware` vem para o resgate, que pode ser configurado em conjunto com o CRA. Descobriu-se que apenas metade dos desenvolvedores de front-end foram capazes de definir tal configuração. Claro, não se pode culpar ninguém aqui, mas tal problema apareceu e deve ser resolvido organizacionalmente.
Uma versão clara de todos os aplicativos com uma descrição da funcionalidade, métodos disponíveis e API interna também é necessária. Isso leva ao próximo problema: documentação.
Problema nº 2. Falta de API interna
Para que os aplicativos interajam muito bem, é necessária documentação. Infelizmente, em nosso caso, apenas microsserviços possuem documentação. E o olhar não caiu sobre os microfrontros.
Esta é uma parte muito crítica do sistema no caso de equipes distribuídas, e mesmo com a rotatividade de pessoal em mente.
Também é necessário desenvolver um mecanismo de comunicação entre aplicativos. Aqui, a `postMessage API` vem para o resgate, ou acesso direto a outro, embutido em quase todos os aplicativos React - Redux. O que não é um ônibus de mensagens? Mas mais sobre isso mais tarde.
Problema nº 3. Iframe não é flexível o suficiente
Não há nada de errado em usar a tag `<iframe />`. É uma ferramenta poderosa com barramento de mensagem integrado (API postMessage) e ampla personalização de segurança.
No entanto, no caso de microfrontings, `<iframe />` impõe muitas restrições. Um deles é a impossibilidade de reutilizar um aplicativo em várias partes da página.
Reutilizar aplicativos
No caso de uma analogia com a loja online, 10 botões Comprar criarão 10 `<iframe />`, ou seja, 10 aplicativos React em execução. Não há memória suficiente para isso. Esse é um dos motivos pelos quais não é possível dividir o aplicativo em equipes por recursos.
URL não é adequado como gerenciamento de estado
Estamos todos acostumados a rotear aplicativos por meio de URLs. Isso também é conveniente no caso de usar o microfront como uma unidade independente. Por exemplo, quando parte do aplicativo principal é coerente o suficiente para ser útil por conta própria. Obviamente, essa não é uma vantagem exclusiva da abordagem iframe, mas é bastante simples de fazer.
Aqui está um exemplo de como um aplicativo roxo do KDPV com uma URL diferente pode funcionar como um aplicativo autônomo:
No entanto, acabou sendo impossível usar a interface de URL iframe para mudar o estado do microfront em nosso caso: o microfront começa a carregar do zero devido à integração incompleta da API de histórico com seu `pushState `e reagir Router - obter um completo página de atualização.
Fora dos manipuladores de clique do ʻiframe`
Imagine que você vai criar um menu suspenso. Como no diagrama acima: no menu rosa. E também feche clicando em um espaço vazio. No caso de um iframe, você precisa usar a API postMessage condicional, uma vez que um clique de saída simplesmente não é reconhecido devido a objetos de janela diferentes. Ou invente um hack com um fundo transparente do elemento iframe ampliado em tela cheia.
A propósito, redimensionar o iframe e ajustar o aplicativo pai a ele também se torna mais complicado e complexo.
Problema de bônus: uso impróprio de cookies
Esse problema não está diretamente relacionado aos microfrontros, mas o leva ao próximo nível de loucura.
Decidiu-se escrever nos cookies de autorização não apenas o token, mas também a lista completa de direitos de certas partes do aplicativo. Tudo isso foi criptografado por SHA - ??? e convertido para base64.
Como resultado, o tamanho do cookie excedeu 8 KB, que é o valor padrão para nodejs / nginx, (ou 2 KB para o tamanho de um registro de Cookie no Google Chrome), o que levou a uma configuração de servidor mais complexa (sem ejetar CRA, você não pode começar com esta configuração), e também para dividir este grande conjunto de dados criptografados em strings de cookies menores.
Isso significa que cada solicitação ao servidor, mesmo para obter `favicon.ico` ou para obter uma lista de seções de menu disponíveis, é equipada com um cabeçalho adicional de um tamanho impressionante.
Conclusão. Como então viver com microfrontros?
Para começar, é claro, você precisa decidir se os microfronts são necessários? Freqüentemente, um kit de IU devidamente configurado e enriquecido na forma de um módulo npm resolve o problema de ambas as versões independentes e do mesmo estilo visual.
- Não use iframe. Isso não simplifica o trabalho, mas apenas adiciona problemas de desempenho, limitando severamente a capacidade de dividir o aplicativo em microfronts. Renderizar pedaços de SPA em tags especialmente reservadas é uma solução muito mais eficiente.
- Desenvolver a orquestração do processo: tanto na produção quanto para o desenvolvimento. Nem todo desenvolvedor gostaria de mergulhar no setor relacionado de roteamento e proxy quando foi contratado para rebitar interfaces de blocos pré-construídos.
- Desenvolva um barramento de mensagens entre aplicativos. Isso é muito mais fácil no caso de um único espaço global, o objeto janela.
- Crie documentação sobre a interface para interação de aplicativos, bem como seu lançamento e configuração.