Atualmente estamos cientes de que, em geral, não devemos ter toda a organização em um único serviço e, portanto, dividimos a arquitetura corporativa em serviços menores, como por exemplo, em microservices. No entanto, também estamos começando a perceber que existem os mesmos problemas com o frontend do monolito, assim como tivemos com o backend, explicou Gustaf Nilsson Kotte em uma recente entrevista apresentada por Stefan Tilkov. Ao usar uma arquitetura micro frontend, divide-se o frontend em partes menores para permitir que as equipes realizem a implantação de forma autônoma, possibilitando assim a entrega contínua de frontends web.
Kotte, consultor de TI da Jayway e atualmente trabalhando como arquiteto web para a IKEA, prefere dividir o sistema verticalmente para criar sistemas auto contidos, com backend e frontend construídos pela mesma equipe. Kotte acredita que equipes com cerca de 10 a 12 pessoas trabalham bem, mas, acima disso, a equipe se torna menos eficiente. Kotte também considera que uma equipe pode trabalhar em mais de um serviço desde que sejam pequenos, embora isso exerça pressão sobre a arquitetura, uma vez que as equipes e os serviços devem ser autônomos.
Quando perguntado por Tilkov como configuraria um grupo de 24 pessoas, Kotte respondeu que não é a favor de criar uma equipe de frontend e duas equipes de backend, argumentando que para uma equipe de backend ser capaz de entregar valor ao usuário final, provavelmente precisará de mudanças feitas pela equipe de frontend. Duas equipes de backend também podem criar uma fila crescente de estórias de frontend. Em vez disso, prefere duas equipes separadas de 12 pessoas, cada uma trabalhando com seus próprios serviços de backend e frontend e podendo implantar em seu próprio ritmo, embora isso traga um novo conjunto de problemas com os quais é preciso lidar, como a colaboração e a reutilização de componentes.
Para Kotte, os microservices tratam-se de arquiteturas heterogêneas e diversas, permitindo diferentes tecnologias, e acredita que isso também deve ser verdade para o frontend. O cenário de frontend ainda está em constante mudança e Kotte tem visto alguns grandes projetos de reescrita de frontends, no qual temos a tendência de subestimar o seu custo. Um ciclo de reescritas de 2 a 4 anos não é bom para os negócios, em vez disso, devemos ter suporte para uma tecnologia diversificada no frontend desde o início.
Não sendo capaz de confiar em um único framework como o React ou Vue, e não escrevendo seu próprio framework, o qual Kotte vê como uma armadilha, a única solução encontrada que permite os mesmos benefícios dos microservices de backend para o frontend é utilizar alguma forma de mecanismo de transclusão - uma maneira de incluir um documento eletrônico em outro documento. No lado do cliente, um exemplo de transclusão é a tag de imagem. A tag tem um atributo de origem que se refere a uma URL e o navegador substituirá a tag com a imagem real durante a renderização - o navegador "transclui" o documento HTML com o documento de imagem.
No lado do servidor, o Edge Side Includes (ESI) corresponde à tag de imagem mas para o HTML. Possui um atributo de origem e a URL aponta para um recurso que deve ser buscado e incluído no documento resultante. O ESI é a tecnologia fundamental na IKEA para o conceito de micro frontends. Apresentam a noção de páginas e fragmentos, e uma equipe terá responsabilidade por um conjunto de páginas e fragmentos. As páginas podem ter referências de ESI a fragmentos, e essas referências podem ultrapassar os limites da equipe. Um exemplo é uma equipe de produto que possui fragmentos para miniaturas de produtos. Outras equipes podem referenciá-las, em vez de criar algo por conta própria.
Como as páginas são montadas por fragmentos produzidos por equipes diferentes e, possivelmente, usando tecnologias diferentes, todos esses fragmentos precisam se encaixar de alguma forma. Para resolver isso, as equipes da IKEA estão usando uma técnica chamada de fragmentos auto contidos, permitindo que tudo que um fragmento precise, como CSS e JavaScript, seja incluído. Não é necessário pensar nas dependências de um fragmento, basta incluir um ESI para estilos e um ESI para scripts, e está feito. Kotte observa que a técnica em si é um pouco complicada, mas para as equipes que a utilizam é bem simples.
Para que páginas e fragmentos funcionem juntos, é preciso apenas configurar algumas regras. Em vez de tentar lidar com tudo o que pode causar problemas antecipadamente, possuem uma abordagem geral de correção rápida de erros, favorecendo o tempo médio de recuperação em relação ao tempo médio entre falhas.
Kotte conclui enfatizando que a arquitetura descrita por ele não necessariamente é a arquitetura certa para todos. Deve-se olhar para as vantagens e desvantagens a nível organizacional e os prós e contras de diferentes modelos para encontrar a melhor solução.
Para aprender mais sobre micro frontends, Kotte recomenda a leitura de seu artigo escrito anteriormente, e sua apresentação sobre Microservice Websites em Øredev 2018. Há também um site dedicado aos micro frontends.