Solução para abstração do processo de integração de fragmentos
dependency-free na arquitetura de micro frontends
Antonio A. C. G. Neto1
1Centro de Informática – Universidade Federal de Pernambuco (UFPE) Av. Jornalista Aníbal Fernandes, s/n - Cidade Universitária - Recife - PE
aacgn@cin.ufpe.br
Abstract. The micro frontends architecture has the potential to bring about profound changes in the frontend software development processes. The single-spa library is currently one of the main tools for building “web” applications that wish to use this type of architecture. In this work, an analysis is performed on a popular library, identifying difficulties in supporting legacy technologies and too many configuration processes. Therefore, the objective of this work is to develop a solution to abstract the fragment integration process, in order to expand support for frontend technologies and facilitate the configuration process. At the end, it was presented the conception of the new tool based on the concept of composition in real time via an iframe and examples of practical use. The solution achieved all the expected objectives; however, I can make reservations about the difficulty of indexing search engines (SEO) and security vulnerability windows, caused by the choice of the composition tool. Thus, it is possible to determine as a scenario of ideal use the market segment of migration of legacy systems, having little attractiveness for real development environments that uses a digital "marketing" strategy due to the previous caveats.
Keywords: Software engineering. Software architecture. Micro frontends. Iframes.
Resumo. A arquitetura de micro frontends tem mostrado o potencial de trazer mudanças profundas nos processos de desenvolvimento de “software” frontend. A biblioteca single-spa é, atualmente, uma das principais ferramentas para construção de aplicações “web” que desejem utilizar este tipo de arquitetura. Neste trabalho, é realizada uma análise sobre a popular biblioteca, identificando dificuldade de suporte às tecnologias legadas e demasiados processos de configuração. Sendo assim, torna-se o objetivo deste trabalho o desenvolvimento de uma solução para abstrair o processo de integração dos fragmentos, de modo a ampliar o suporte às tecnologias frontend e facilitar o processo de configuração. Ao final, foi apresentada a concepção da nova ferramenta baseada no conceito de composição em tempo real via iframe que e exemplos de utilização prático. A solução alcançou todos os objetivos esperados; entretanto, trouxe consigo ressalvas quanto à dificuldade de indexação a sites de busca (SEO) e janelas de vulnerabilidade de segurança, causadas pela escolha da ferramenta de composição. Assim, consegue-se determinar como cenário de utilização ideal o segmento de mercado de migração de sistemas de legados, possuindo pouca atratividade para ambientes de desenvolvimento real que se utilize de estratégias de “marketing” digital devido aos pontos de ressalva anteriormente descritos.
Palavras-chave: Engenharia de software. Arquitetura de software. Micro frontends. Iframes.
1. Introdução
No passado, um grande número de aplicações web adotava a arquitetura monolítica devido à baixa complexidade de requisitos da época [1]. Essa arquitetura orientava o tratamento de módulos funcionais e a transmissão de dados como um todo, sendo uniformemente configurados, desenvolvidos e implementados [2]. Porém, a partir do
dificuldades conceitos como a separação por funcionalidades, novas tecnologias e arquiteturas ganhavam popularidade. O código base das aplicações passou a ser segmentado em diferentes grupos: Frontend, responsável pelo fornecimento de uma interface de interação entre o usuário e o sistema, e Backend, que em muitos casos era responsável pelo processamento de dados [4]. Entre as diversas técnicas de desenvolvimento Backend, a arquitetura de Microservices começou a ganhar destaque [3] especialmente no que se referia a escalabilidade de sistemas [4].
A Arquitetura baseada em Microsserviços (Microservices-Based Architecture, MBA) prezava pelo desenvolvimento de pequenos serviços que se concentravam em um único contexto de negócio [5], criando um código fracamente acoplado e altamente coeso. Assim, possibilitaram a criação de uma boa modularidade no código base e permitiam enfrentar os problemas de escalabilidade que dificultavam as alterações ou adições de novas funcionalidades nas soluções que eram desenvolvidas.
Os benefícios do uso de MBAs chamaram bastante atenção para pesquisadores e desenvolvedores, sendo cada vez mais testados e comprovados. Assim, tomou-se como uma boa ideia a aplicação dos conceitos dessa arquitetura no grupo de Frontend [1], originando um estilo arquitetural que faria a decomposição de uma aplicação frontend maior em menores unidades segmentadas por funcionalidade e passaria a ser conhecida como a arquitetura de micro frontends [6].
Algumas poucas soluções tentaram abstrair o processo de integração dessa arquitetura, sendo o framework single-spa, atualmente, o mais conhecido e utilizado [7]. Após estudos de exemplos e da documentação, foi passível de identificação a obrigatoriedade de utilização de um plugin específico para cada tipo de tecnologia frontend existente nos fragmentos e que serviria para a realização do controle de ciclo de vida e integração com a aplicação contêiner. Esse plugin só reconhece aplicações desenvolvidas no lado de cliente, impõe restrição às tecnologias legado que eram desenvolvidas no lado do servidor e acaba descentralizando a lógica de configuração das micro aplicações.
Diante do exposto, trata-se como objetivo geral deste trabalho desenvolver uma ferramenta que abstraia o processo de integração de micro frontends sem obrigar a instalação de dependências obrigatórias, como os plugins do single-spa. Assim, facilitando o desenvolvimento de aplicações que desejem utilizar este tipo de arquitetura e ampliando o suporte a mais tecnologias.
Dado o acumulado de referencial teórico, estruturada a metodologia de desenvolvimento e obtidos os resultados, é realizada uma análise da construção da ferramenta e da aplicabilidade da solução em relação aos seus objetivos específicos.
O trabalho está estruturado da seguinte forma: seção 2 descreve o contexto no qual está envolvido o estudo; seção 3 informa os procedimentos referentes à metodologia de trabalho aplicada para conduzir a produção dessa ferramenta; seção 4 relata os resultados do desenvolvimento da solução; seção 5 apresenta uma discussão dos resultados encontrados; seção 6 traz as conclusões deste trabalho e aponta as direções futuras.
2. Contexto
Nas subseções seguintes serão descritos os fundamentos teóricos que deram suporte a concepção da ferramenta.
2.1. Arquitetura monolítica
Segundo Krishnamurthy, uma arquitetura monolítica descreve uma aplicação de “software” de camada única, onde todos os serviços e componentes estão combinados em uma única solução [2].
Uma aplicação monolítica é aquela que usa uma única base de código para servir a vários serviços e “interfaces” diferentes, como REST, APIs e páginas HTML. Ainda hoje, é considerada a forma padrão para começar a desenvolver aplicações. Uma única base de código facilita o desenvolvimento, implantação e escalonamento do aplicativo, desde que o tamanho seja relativamente pequeno [19].
A maioria dos aplicativos pode ser bastante simples no início, mas à medida que o tempo e a aplicação cresce, o mesmo acontece com sua complexidade. Uma maneira típica de lidar com isso é dividindo o aplicativo em diferentes camadas: uma camada de interface de usuário (IU), uma camada de serviço e um acesso a dados.
No entanto, conforme o tamanho do aplicativo e da organização cresce, também crescem as diferentes camadas da aplicação. A menos que se dê muita atenção à arquitetura e qualidade da base de código, é muito provável que a qualidade das diferentes camadas se deteriore. A deterioração acontece devido aos requisitos de negócios que forçam desenvolvedores a fazer soluções que não são ideais. Como o tamanho da base de código cresce e a qualidade da base de código se deteriora, fica mais difícil adicionar novos recursos e modificar recursos antigos porque o desenvolvedor tem que encontrar o lugar correto para aplicar essas mudanças. Isso resulta em ciclos de desenvolvimento mais lentos.
2.2. Arquitetura de microsserviços
Como solução para mitigar os problemas descritos na seção anterior, surgiu em 2012 a arquitetura baseada em microsserviços.
Essa arquitetura se define pela construção de pequenos serviços que se concentram em um único contexto de negócio. Por exemplo, um microsserviço poderia lidar com a criação de pedidos e outro microsserviço poderia lidar com a criação de uma
camadas de serviço em microsserviços. Suas experiências positivas e de longo prazo com este estilo de arquitetura atraiu o interesse de muitas outras empresas e desenvolvedores.
2.3. Arquitetura de micro frontends 2.3.1. Definição
Mesmo com a evolução arquitetural dos últimos anos e redução de limitações de grandes backends e monolíticos, as bases de código frontend continuavam complexas e dificilmente escaláveis [6].
Dado esse contexto, foi imaginado como se tirar proveito dos benefícios de modularização e escalabilidade presentes na arquitetura de microsserviços e replicar seus efeitos no frontend. Desse “mix” foi originada a arquitetura de micro frontends.
Cam Jackson define a arquitetura como um “estilo” no qual aplicações frontend são entregues de maneira independente e são compostas em uma aplicação maior [6].
Krishnamurthy, por sua vez, descreve o micro frontend como uma abordagem de microsserviços, porém aplicado no frontend, onde a ideia é decompor a aplicação web em unidades menores e segmentadas por funcionalidade [20].
Yang et al. [20] dizem que a ideia do micro frontend é tratar uma aplicação web como uma combinação de recursos onde cada time cuida de uma parte desta aplicação e atende a um negócio ou função específico.
Se comparada a orientação de arquitetura de “web mashups”, definida como aplicação que combina conteúdos (como dados e código) de várias fontes em uma experiência integrada para um usuário [18], a diferença estaria no controle e direcionamento das aplicações externas presentes na aplicação contêiner. A arquitetura de micro frontends dita que a equipe de desenvolvedores deve ter total controle de acesso a escrita do código fonte das micro aplicações, e estas devem na maioria das vezes limitar a liberação de acesso a uma única origem (a da aplicação contêiner). Enquanto isso, os “web mashups” utilizam artefatos públicos que permitem acesso de qualquer tipo de origem e que os desenvolvedores em suma maioria não terão controle de acesso a escrita do código fonte das micro aplicações.
Cada micro aplicação deve ser implementada de forma autônoma, modular e bem delimitada, sendo possível alcançar uma evolução independente [8]. Assim,
alterações de tecnologias antigas deixam de ser dependentes de uma reescrita integral do código base.
Podemos reunir as ideias principais da arquitetura de micro frontends nos seguintes tópicos [8]:
● Modelagem em torno de domínios de negócio; ● Abstração de detalhes de implementação; ● Deployments independentes;
● Isolamento de falhas.
2.3.2. Parâmetros de orientação
Dada a definição e ideias centrais, é importante entender que a arquitetura de micro frontends apresenta diversas formas de implementação que variam de acordo com alguns parâmetros de orientação. Estes parâmetros irão definir seu modelo de separação, composição / renderização e comunicação.
2.3.2.1. Separação
O parâmetro de separação refere-se a distribuição do modo de exibição e ao escopo de trabalho dos times dentro de cada fragmento. As comuns escolhas de discussão são:
● Separação horizontal, com múltiplos micro frontends por página; ● Separação vertical, com apenas um micro frontend por página.
Figura 2. Separação vertical 2.3.2.2. Composição
Por sua vez, a composição refere-se à forma de renderização da aplicação. As comuns escolhas de discussão estão nas seguintes opções:
● Composição no lado do cliente; ● Composição central;
● Composição no lado do servidor.
Figura 3. Representação visual das técnicas de composição
A composição realizada no lado do cliente sugere que a aplicação contêiner carregue todos os seus micro frontends diretamente do Content Delivery Network (CDN), uma rede de distribuição de conteúdo para entregar a página a partir do servidor mais próximo do usuário, ou de sua origem, caso ainda não tenha sido guardado em cache, a partir de um ponto de entrada JavaScript. Assim, o contêiner consegue
adicioná-los dinamicamente aos nós do Document Object Model (DOM), em caso de ser um HTML, ou inicializar a aplicação JavaScript. Uma outra possibilidade é a utilização de iframes.
Já utilizando a composição central, o conteúdo da página será montado e armazenado em múltiplos CDN que utilizam um tipo de Extensible Markup Language (XML) chamado Edge Side Include (ESI) que possibilitará a escalabilidade da infraestrutura da aplicação provida pela exploração de pontos de CDN espalhados pelo mundo, assim aumentando de capacidade de hosting do data center comparada a uma aplicação comum. Porém, uma das desvantagens é que a utilização do ESI não é feita da mesma forma para cada CDN e, portanto, uma estratégia multi-CDN poderia resultar em vários re-trabalhos de implementação [10].
Por sua vez, a composição no lado do servidor detém seu conteúdo primariamente de sua origem e armazena a informação no CDN, servindo ao cliente a tela final em tempo de execução ou compilação.
2.3.2.3. Comunicação
A comunicação entre micro frontends ocorrerá de acordo com o modelo de separação escolhido. No caso da separação horizontal, um método é a utilização de disparadores de evento providos pelo browser ou por objetos construídos pelo usuário dentro de cada micro frontend. Dessa maneira, quando um fragmento emitir um evento, o outro conseguirá obter a informação a partir de subscrições realizadas naquele evento em específico. Outras propostas de utilização são os eventos customizáveis, que são visíveis apenas nos contextos de janela em que foram emitidos.
Figura 5. Fluxo de requisição da aplicação
Para a separação vertical poderá ser utilizada a passagem de variáveis via query string ou suporte das ferramentas de armazenamento nativas do navegador, como Localstorage, Sessionstorage, Cookies, IndexedDB e outros.
2.4. Single-SPA
Atualmente, a biblioteca single-spa é uma das principais ferramentas construídas em JavaScript, de código aberto, para construção de interfaces de usuário na web que desejem utilizar a arquitetura de micro frontends. Foi desenvolvido pelo grupo Canopy com o objetivo de reunir vários micro frontends em uma única aplicação. Hoje, o single-spa é utilizado por diversas companhias como Canonical, Zup, Scania e outras.
Uma aplicação desenvolvida com o single-spa consiste na criação de um projeto contêiner e vários outros projetos de diferentes tecnologias.
Logo após os primeiros estudos de exemplos e da documentação da ferramenta, foi percebida a seguinte condição: Todas as micro aplicações desenvolvidas eram obrigadas a utilizar um plugin específico que desse suporte a sua stack de desenvolvimento, permitindo a configuração dos métodos de ciclo de vida e o integrando a aplicação contêiner . Esse plugin só considera como artefatos de micro aplicações as ferramentas desenvolvidas com conteúdo renderizável no lado do cliente e que descentraliza parte do processo de configuração de ciclo de vida e integração. Com isso, dificulta a utilização da tecnologia em ferramentas antigas que majoritariamente trabalhavam com renderização no lado do servidor e que hoje almejam realizar a migração de seu sistema para alguma solução mais moderna.
É dessa identificação de suporte restritivo, descentralização de configuração e pequeno acervo de soluções atacando este tema que nasce como objetivo deste trabalho
o desenvolvimento de uma solução que seja capaz de abstrair a integração dos fragmentos em um único contêiner sem a instalação de dependências obrigatórias, como os plugins, nos fragmentos, focando em um tipo de construção que dê às micro aplicações uma maior liberdade de escolha de tecnologias e facilite a configuração de aplicações com esse tipo de arquitetura.
3. Metodologia de trabalho
Este trabalho compreende uma proposta de desenvolvimento prática realizada com base nas diretrizes teóricas compreendidas na seção anterior. Assim, nas subseções seguintes serão descritos os passos práticos que auxiliaram o processo de desenvolvimento e validação da ferramenta.
3.1. Escolha de parâmetros orientadores
Essa etapa compreende as escolhas referentes aos métodos de separação, composição e comunicação dos micro frontends a partir dos problemas citados e objetivos a serem atingidos.
Devido aos itens desejáveis de entrega, a necessidade de baixo tempo de implementação e conhecimento prévio de tecnologias específicas do autor, os orientadores de implementação escolhidos foram: a separação vertical, composição no lado do cliente por auxílio de iframes e comunicação entre micro frontends auxiliada por evento no modelo publish / subscribe.
Uma vez que os parâmetros orientadores foram escolhidos, foi realizada uma sessão de brainstorming.
3.2. Brainstorming
O propósito de se realizar o “brainstorming”, técnica utilizada para propor soluções a um problema específico, foi garantir uma maior diversidade de opções para a escolha da solução final.
Dado esse contexto, foram pensadas algumas arquiteturas. As soluções que demonstraram estar fora do esperado, não contendo todos os parâmetros orientadores definidos ou que não conseguiriam ser executados em tempo hábil, foram eliminadas, garantindo assim a permanência das que realmente estavam alinhadas à proposta. Ao final desse processo, dentre as opções pensadas, a de codinome Roll Cake foi escolhida. A relação completa das soluções pensadas e excluídas pode ser encontrada no apêndice A.
3.3. Solução
A solução de codinome Roll Cake contemplaria três módulos JavaScript com responsabilidades únicas e suas próprias interfaces de programação de aplicativos (API), sendo eles:
● Roll Cake MF-Broker: um mediador de micro frontends; ● Roll Cake Router: um mediador de rotas;
Figura 6. Solução Roll Cake
3.3.1. Módulo MF-Broker
O módulo mf-broker recebe esse nome por atuar como um middleware entre o cliente web e os vários micro frontends da aplicação, assim como uma arquitetura broker de mensageria. O mesmo deverá identificar quais fragmentos deverão ser inseridos em tela e preparar um ambiente de comunicação e armazenamento de dados totalmente compartilhável entre eles e a aplicação. Pode-se, inclusive, considerar este módulo como o artefato de maior valor agregado do projeto.
Importante citar que este módulo foi estruturado focado, principalmente, na liberdade e facilidade de implementação para outras soluções de SPA Frameworks, permitindo ao usuário utilizar o mediador de micro frontends em uma aplicação contêiner com qualquer tecnologia desejada.
Figura 7. Arquitetura de controle de micro frontends
Figura 8. Arquitetura de comunicação de micro frontend
3.3.2. Módulo Router
O módulo router é o responsável por realizar a identificação e controle de rotas da aplicação no lado do cliente. Assim, o mesmo deverá ao contar com eventos de navegação, manipulação de histórico de navegação, e cenários de identificação de mudança de rota na qual deverá emitir um evento de notificação contendo um artefato relacionado àquele endereço.
Figura 9. Arquitetura do router
3.3.3. Módulo SPA
Por sua vez, o módulo do SPA será o responsável pela utilização e integração de todos os módulos anteriores, juntamente com a capacidade de renderização, destruição e atualização de elementos em tela.
Seu ciclo deve se iniciar com a observação de modificações de rota, realizada pelo módulo router, assim identificando qual item deve ser renderizado em tela e realizando a ação de inserção.
Logo após a renderização do elemento, o módulo mf-broker irá identificar se o item é um custom element reconhecido por sua lógica de desenvolvimento e, caso seja, serão observados os atributos declarados na renderização do elemento e sua relação com os dados internos disponíveis no módulo.
Confirmada a relação entre os atributos do elemento e os dados disponibilizados para o mf-broker, será estabelecida uma ponte de comunicação com o SPA para a identificação do começo e término do processo de requisição de micro frontends e será realizada uma solicitação de conteúdo do fragmento. Solicitação essa que, enquanto terá suas trativas sendo realizadas, fará o SPA realizar uma sobreposição de tela com um componente de carregamento.
Assim que a requisição for finalizada, o SPA removerá a sobreposição de tela e o custom element terá em seu conteúdo o elemento de iframe disponibilizado pelo módulo do mf-broker.
Figura 10. Arquitetura do SPA com todos os serviços integrados
3.4. Plano de distribuição
Pensando na disponibilização gratuita da ferramenta foram escolhidos canais de distribuição que permitissem alta visibilidade da comunidade de desenvolvimento, acesso à ferramentas de inserção e inspeção de código, quadro de problemas e atividades e histórico de versões. Sendo as seguintes ferramentas selecionadas:
● Github: Uma plataforma de hospedagem de código-fonte e arquivos;
● Github Packages Registry: Um serviço de hospedagem de pacotes de software.
3.5. Cenário de exemplificação
Para demonstrar o funcionamento da solução, foi definido a construção de um cenário de exemplificação que tivesse como requisitos obrigatórios a utilização de todas as funcionalidades providas pela API da ferramenta a ser concebida, fragmentos de pelo menos 3 tecnologias de frontend distintas e que possuíssem ao menos um pouco de semelhança visual e funcional com alguma ferramenta ou serviço muito utilizado durante a data de publicação deste trabalho.
Dado esse contexto, o cenário de exemplificação escolhido foi o desenvolvimento de um SPA clone do serviço de streaming musical Spotify. Serviço o
Figura 11. Página de login do Spotify
Figura 12. Página do web player do Spotify
4. Resultados
Esta seção fornece uma descrição funcional dos artefatos implementados a partir das diretrizes traçadas na seção anterior.
4.1. Módulo MF-Broker
O módulo mf-broker foi construído sob a utilização da linguagem de programação JavaScript com o auxílio do gerenciador de pacotes npm e as seguintes bibliotecas:
● Babel: realiza a transpilação do código para versões minificadas e de maior suporte nativo a navegadores;
● Eslint: verifica de boas práticas na escrita de código;
● Lodash: abstrai funções comumente utilizadas no JavaScript;
● Rxjs: disponibiliza uma interface de criação de eventos de comunicação do tipo publish / subscribe.
Seis artefatos foram necessários para realizar seu funcionamento, sendo eles: ● EventBus: uma classe que representa a interface de comunicação no modelo
publish / subscribe;
● GlobalStore: uma classe responsável pelo compartilhamento e persistência de dados;
● Microfrontend: uma classe responsável pela identificação e tratamento de Custom Elements com a tag “rollcake-microfrontends”;
● RollCakeMFBroker: uma classe dedicada a integração de serviços internos e transmissão de eventos;
● Um armazenador de constantes para re-utilização de variáveis; ● Um arquivo exportador de itens.
Dentre os itens citados, apenas dois estão disponíveis para utilização pública: a classe RollCakeMFBroker e as constantes referentes ao nome da variável de janela criada pelo módulo, ao nome da Custom Tag referente aos micro frontend e ao nome dos eventos públicos cabíveis de recebimento.
A partir da instalação do módulo, se o usuário quiser utilizar a ferramenta terá que realizar a configuração da classe RollCakeMFBroker. A classe possuirá apenas um parâmetro de entrada do tipo lista de objetos que deverá armazenar as declarações de micro frontends que desejam ser atribuídas a aplicação. Nesse objeto devem ser informados os atributos name e address.
Tabela 1. Exemplo de declaração e inserção de parâmetros da classe RollCakeMFBroker
Após realizada a instância da classe, o construtor disponibiliza ao usuário um método de inicialização chamado init que define como atributo interno o objeto que conterá a lista de buckets e instância as classes EventBus e GlobalStore para, posteriormente, compartilhá-los através das variáveis de janelas.
Tabela 2. Exemplo de execução do método init
Criada a variável de janela, a classe Microfrontend passa a detectar a inserção de elementos com a tag “rollcake-microfrontend” no HTML do cliente. A partir de sua detecção, é lido o parâmetro name e dele é tentado achar alguma referência com a declaração dos buckets feitas na instância da classe RollCakeMFBroker. Se passível de pareamento, será criada uma resposta encapsulada em um iframe, que conterá uma cópia da variável de janela compartilhável previamente descrita no parágrafo anterior, e será feita uma requisição para adquirir o HTML content do address encontrado. Se a
import { RollCakeMFBroker } from '@rollcakejs/rollcake-mf-broker';
const MFBroker = new RollCakeMFBroker([{ name: 'react-bucket',
address: 'https://localhost:3000' }]);
4.2. Módulo Router
O módulo router foi construído sob as mesmas escolhas de tecnologias e ferramentas da seção anterior.
Necessitou-se de apenas três artefatos para sua implementação, sendo eles: ● RollCakeRouter: Uma classe responsável pela identificação e controle de rotas; ● Um armazenador de constantes;
● Um arquivo exportador de itens.
Dentre os itens citados, dois foram disponibilizados para utilização do usuário: a classe RollCakeRouter e a constante referente aos modos de navegação implementados.
No construtor da classe RollCakeRouter é recebível como parâmetro de entrada um tipo objeto que deverá conter dois atributos: routes e mode. O atributo routes é uma lista de objetos do tipo route, que possui como atributos internos o path e o item, o qual o path é o parâmetro de orientação de exibição e o item é o valor a ser exibido. Enquanto isso, o mode é um atributo tipo texto que terá uma variação de dois valores: hash e history. A diferença entre os dois modos é a interpretação do navegador para o registro de roteamento e uma pequena diferença visual, possível de ser vista na Tabela 6.
Tabela 5. Exemplo de declaração e inserção de parâmetros da classe RollCakeRouter window.RollCake.bus.subscribe(eventName, callback); // GlobalStore window.RollCake.store.getState(stateName); window.RollCake.store.setState(stateName, newState);
import { RollCakeRouter, NAVIGATION_MODE } from '@rollcakejs/rollcake-router'; import ReactPage from './pages/ReactPage';
const Router = new RollCakeRouter({ routes: [
{ path: '/react', item: ReactPage } ],
mode: NAVIGATION_MODE.HISTORY });
Tabela 6. Diferença de URI entre os modos de roteirização
Após instância de sua classe, o atributo routes é registrado como valor interno e o atributo mode é verificado para, a partir de seu valor, alterar as funções de navegação e localização da rota. Também, ocorre a disponibilização de um método de inicialização chamado init, para realizar a identificação de mudança de rota e retornar um callback, contendo o path e o item da nova rota para seu watcher realizar a tratativa deste evento.
Tabela 7. Exemplo de declaração e utilização do método de init
4.3. Módulo SPA
Assim como o módulo anterior, o SPA foi construído sob as mesmas escolhas de tecnologias e ferramentas da seção referente ao mf-broker, porém com um código fonte mais complexo devido aos métodos de integração com os outros módulos e a sua responsabilidade de renderização de elementos, necessitando de sete artefatos para execução de todas as suas tarefas:
● RollCakeSpa: uma classe responsável pela inicialização dos outros módulos e integração com as funções do SPA;
● Page: uma classe responsável pela renderização de páginas; ● Element: uma classe responsável pela renderização de elementos; ● createPage: uma função responsável pela criação de páginas;
● createElement: uma a função responsável pela criação de elementos; ● Um compartilhador de constantes;
● Um exportador de artefatos deste e dos outros módulos.
Os itens públicos disponibilizados para o usuário final são: a classe
RollCakeSpa, a classe RollCakeRouter, a classe RollCakeMFBroker, as funções de criação de página e elemento, e algumas constantes.
Para a utilização do módulo é necessária a implementação da classe RollCakeSpa. Nela é feito o recebimento de três parâmetros obrigatórios e um opcional, sendo esses: o MFBroker, router, entryDOMNode e o loadingContent (opcional).
Modo URI Hash https://server:port/#/home History https://server:port/home Router.init((props) => { console.log(props.path); console.log(props.item); });
Ao ser instanciado, ele realiza a chamada de inicialização das classes RollCakeMFBroker e RollCakeRouter.
Uma vez que o módulo MF-Broker seja inicializado, ele realizará a disponibilização das mediações de micro frontends e a interface de comunicação entre elas. Posteriormente, a partir da interface de comunicação, o SPA passará a escutar eventos de requisição, para fazer a sobreposição de tela com o conteúdo do atributo loadingContent, e solicitação de navegação, para requisitar ao módulo router uma navegação forçada.
Logo em seguida, o router é inicializado para detecção de mudança de rotas. Uma vez que algo seja detectado, ele fará uma verificação de existência perguntando a seus atributos internos se existe alguma página atualmente visível para o usuário e, caso exista, vai deletá-la para solicitar a renderização do novo item. Item este que deverá ser do tipo função e ter como retorno referência ao artefato createPage disponibilizada publicamente por este módulo.
O createPage irá realizar a criação da classe page que, ao ser instanciada, irá em seu construtor fazer a atribuição de valores internos e realizar a execução de métodos de renderização e destruição que irão ativar funções internas ao ciclo de vida da aplicação. No caso do método render é disparada a ativação dos atributos do tipo função onInit e content, o qual o content deverá ter como retorno obrigatório uma instância da classe element que será responsável pela inserção de conteúdo no DOM.
}]);
const Router = new RollCakeRouter({ routes: [{ path: '/react', item: ReactPage }], mode: NAVIGATION_MODE.HISTORY });
Tabela 9. Exemplo de declaração e inserção de parâmetros da função createPage
Tabela 10. Exemplo de declaração e inserção de parâmetros da função createElement
Um ponto importante da exemplificação da Tabela 12 é a definição de um elemento de micro frontends. Para seja realizada uma mediação do broker com sucesso, é necessário solicitar a criação de um elemento que possua em sua declaração de tag com o valor “rollcake-microfrontend” e no atributo attr adicionar a chave “name” com um valor correspondente ao bucket declarado na referência de configuração da classe RollCakeMFBroker.
4.4. Plano de distribuição
Para a disponibilização do conteúdo deste trabalho foi criada uma organização na plataforma Github chamada rollcakejs. Essa organização contém os repositórios dos três módulos JavaScript com controle de versão feito pela ferramenta git e disponibiliza a utilização do pacote com auxílio do Github Package Registry. O link de acesso para a organização é o: https://github.com/rollcakejs.
4.5. Cenário de exemplificação: Spotify Clone
O Spotify Clone, foi construído sob a implementação de um mono-repositório majoritariamente com um código fonte desenvolvido em JavaScript e auxiliado pelo gerenciador de pacotes yarn.
import { createPage } from '@rollcakejs/rollcake-spa'; import ReactBucket from ‘../components/ReactBucket’;
const ReactPage = () => createPage({
onInit: function() { console.log('initialized!') }, onDestroy: function() { console.log('destroyed!') }, onUpdate: function() { console.log('updated') }, content: function() {
return ReactBucket() }
});
export default ReactPage;
import { createElement, CUSTOM_ELEMENT_TAG} from '@rollcakejs/rollcake-spa';
const ReactBucket = () => createElement({
tag: CUSTOM_ELEMENT_TAG.MICROFRONTEND, attr: { name: 'react-bucket' } });
instalação e configuração do pacote lerna, o qual ajudará a realizar a manutenção e automação de tarefas dentro do repositório, além de configurar o workspaces (uma feature disponibilizada pelo gerenciador de pacotes para agrupar dependências em comum). Desse modo, é possível executar simultaneamente todas as aplicações contidas no projeto bastando digitar o comando lerna run start:dev em um terminal de comando.
É importante citar que para acelerar o desenvolvimento de novos projetos com essas ferramentas e estruturação foi disponibilizado na organização rollcakejs, no Github, um repositório contendo um template inicial para a abstração de todo processo de preparo do ambiente de desenvolvimento.
4.5.1. Aplicação contêiner
Na pasta app estará armazenada a aplicação contêiner que fará a configuração e integração de todos os micro frontends, ou seja, é onde estará concentrada a solução desenvolvida nesta proposta de experimentação.
Assim como todas as outras aplicações presentes no repositório, essa pasta terá um package.json próprio para o gerenciamento de dependências, controle de publicação e criação de scripts.
Figura 14. Estrutura de organização da camada app
Para construção do ambiente de desenvolvimento, foram utilizados os pacotes babel, webpack e webpack-dev-server. Toda concentração de esforços de controle e configuração serão realizados no arquivo webpack.config.js, o qual deverá conter loaders e plugins para realização de leitura e tratamento de arquivos css, assim como deverá realizar a transpiração, minificação de código JavaScript para aumento de cobertura de suporte a navegadores e fazer a indexação dos arquivos encontrados na pasta public a um servidor local. Importante ressaltar que entre os arquivos disponibilizados na pasta public, deverá estar um arquivo index.html que conterá um script tag com referência ao arquivo index.js da pasta src e uma div tag com um atributo
id de qualquer valor que será utilizado como referência para o entryDOMNode da classe RollCakeSpa.
Finalizado o pré-setup do ambiente é possível focar na estruturação e implementação da pasta src com o arquivo index.js e seus derivados, criando os seguintes artefatos: mf-broker.config.js, router.config.js, global.css, pasta components, pasta pages e o próprio index.js.
Figura 15. Estrutura de organização da pasta src
O arquivo mf-broker.config.js contém como pacote de referência a solução MF-Broker, trazendo consigo todos os registros referentes aos micro frontends e realizando a exportação do objeto RollCakeMFBroker.
Tabela 11. Exemplo de arquivo mf-broker.config.js import { RollCakeMFBroker } from '@rollcakejs/rollcake-spa';
const buckets = [ { name: 'authentication-bucket', address: 'http://localhost:3000' }, { name: 'menu-bucket', address: 'http://localhost:3001' }, { name: 'player-bucket', address: 'http://localhost:3004' }, { name: 'playlist-board-bucket', address: 'http://localhost:3003' } ];
A pasta pages armazena vários folders internos com arquivos index.js e index.css que estão importando estilizações e exportando uma constante do tipo função com retorno para a chamada createPage, constante essa que deverá ser importada e referenciada pelo arquivo router.config.js (como demonstrado no parágrafo anterior).
Tabela 13. Exemplo de arquivo index.js de um page { path: '/', item: AuthenticationPage},
{ path: '/dashboard', item: DashboardPage } ];
export default new RollCakeRouter({ routes,
mode: NAVIGATION_MODE.HISTORY });
import { CONTEXT_ATTRIBUTE, createPage, PUBLIC_BUS_PUBLISH_EVENT_TYPE, WINDOW_VARIABLE } from ‘@rollcakejs/rollcake-spa’;
import AuthenticatioMf from ‘../../components/AuthenticationMf’; import ‘./index.css’;
const AuthenticationPage = () => createPage({ onInit: function() {
const winVar= window[WINDOW_VARIABLE.ROLLCAKE]; const store = winVar[CONTEXT_ATTRIBUTE.STORE]; const bus = winVar[CONTEXT_ATTRIBUTE.BUS]; if (store.getState('authentication')) { bus.publish(PUBLIC_BUS_PUBLISH_EVENT_TYPE.NAVIGATE_TO, '/dashboard'); } else { bus.subscribe('authorized-user-callback', () => { store.setState('authentication'); bus.publish(PUBLIC_BUS_PUBLISH_EVENT_TYPE.NAVIGATE_TO, '/dashboard'); }); } }, content: function() { return AuthenticatioMf(); } });
A pasta components também armazenará vários folders internos com arquivos index.js e index.css que também estão importando estilizações, porém exportando uma constante do tipo função com retorno para a chamada createElement. A ideia é que estes itens possam ser utilizados como retorno no atributo content do tipo função encontrado como parâmetro de entrada na chamada do artefato createPage, presente nos itens da pasta pages.
Tabela 14. Exemplo de arquivo index.js de um component
Por fim, o arquivo index.js faz a importação dos artefatos de alto nível como o global.css, que registra todas as estilizações globais da aplicação, o router.config.js, o mf-broker.config.js e a classe RollCakeSpa, fazendo assim a declaração da classe e colocando alguns dos itens importados como parâmetros de entrada.
Tabela 15. Exemplo de arquivo index.js
4.5.2. Micro frontends de autenticação
O módulo de authentication é o primeiro fazendo referência à criação, de fato, de uma aplicação que se tornará um Micro frontend. Ele e todos os próximos módulos a serem discutidos estão presentes na pasta de micro-apps.
Esse fragmento deverá ser responsável por realizar toda a configuração de autenticação e autorização do usuário. Sua tecnologia de desenvolvimento frontend foi o Vue.js [11], sendo utilizadas as dependências comuns a projetos vue e o spotify-web-api-node, o qual estará presente na maioria dos módulos dos fragmentos e fará requisições para a api do Spotify.
Após toda criação do ambiente de desenvolvimento com a utilização do Vue CLI, foram configurados alguns componentes básicos e definidas duas rotas: login e callback. A página de login é a ferramenta de interação virtual do usuário que deverá
import { createElement, CUSTOM_ELEMENT_TAG } from ‘@rollcakejs/rollcake-spa’; import ‘./index.css’;
const AuthenticatioMf = () => createElement({
tag: CUSTOM_ELEMENT_TAG.MICROFRONTEND, attr: { name: 'authentication-bucket', class: 'microfrontend' } });
export default AuthenticatioMf;
import { RollCakeSpa } from ‘@rollcakejs/rollcake-spa'; import MFBroker from './mf-broker.config';
import Router from './router.config';
import LoadingOverlay from './components/LoadingOverlay'; import './global.css';
4.5.3. Micro frontends de menu
Por sua vez, o módulo menu é uma aplicação que terá a responsabilidade de disponibilizar ao usuário o acesso de suas playlist no Spotify além de, futuramente, agregar métodos de navegação no SPA.
Como forma de contribuir para a diversidade de ferramentas utilizadas na aplicação contêiner, sua tecnologia de desenvolvimento frontend escolhida foi o Angular [12]. Já as bibliotecas de suporte foram as dependências comuns a projetos angular e o spotify-web-api-node.
Toda configuração e estilização do fragmento foi realizado nos arquivos de prefixo app, esperando-se um componente interativo com semelhança visual ao menu encontrado na página oficial do WebPlayer do Spotify, consumindo dados do módulo anteriormente apresentado e, principalmente, disponibilizando uma lista de playlist do usuário que poderá ser clicada e, posteriormente, transmitida para a micro-aplicação player pela interface de comunicação da solução MF-Broker.
Tabela 17. Exemplo de obtenção do valor referente ao ao usuário autenticado
Tabela 18. Exemplo de envio de evento para reprodução da playlist selecionada
4.5.4. Micro frontends de quadro de faixas musicais
Para o módulo playlist-board seu produto será uma aplicação com a responsabilidade de disponibilizar ao usuário um quadro de playlist recomendadas pelo Spotify.
E, novamente, como forma de contribuição para a diversidade de ferramentas utilizadas na aplicação contêiner, a tecnologia de desenvolvimento frontend escolhida
if (window.RollCake) { window.RollCake.bus.publish("authorized-user-callback", {accessToken: xXxXxXxXxXxXx}); } if ((<any>window).RollCake){ const authorizedUser = (<any>window).RollCakeMFBroker.store.getState('authentication'); } (<any>window).RollCake.bus.publish('play-user-playback',context_uri);
foi o React [13] com as dependências comuns a projetos react e, novamente, o spotify-web-api-node.
Foram criados alguns componentes básicos e todos foram agrupados em um único componente pai. Esse componente de maior nível hierárquico estaria indexado a página inicial da micro-aplicação que teria os mesmos propósitos que os módulos anteriores: interação virtual com o usuário e semelhança visual com a página oficial de WebPlayer do Spotify. Portanto, o fragmento deverá consumir os dados do módulo de autenticação e, principalmente, disponibilizar uma lista de playlists recomendadas, que poderá ser clicada e posteriormente transmitida para a micro-aplicação player pela interface de comunicação da solução MF-Broker.
4.5.5. Micro frontends de reprodução musical
Dentro do módulo player será disponibilizada uma aplicação com a responsabilidade de oferecer ao usuário o reprodutor musical do Spotify dentro do navegador, além de realizar o consumo de eventos dos outros micro frontends e executar as ações requeridas.
Sua tecnologia de desenvolvimento frontend escolhida foi o Svelte [14] e teve com suas dependências de projeto algumas das bibliotecas mais comuns para a construção de projetos em Svelte e a dependência mais utilizada entre todos os fragmentos: o spotify-web-api-node.
Dentro da composição de seu arquivo de configuração principal foi feita a integração entre os serviços de requisição disponibilizados pela biblioteca spotify-web-api-node e o SDK disponibilizado pelo próprio Spotify para implementação abstrata das funcionalidades do player. Assim, o fragmento deverá consumir os dados do módulo de autenticação, integrar o SDK e as requisições da biblioteca spotify-web-api-node, além de consumir os eventos providos do MF-Broker e efetuar as ações esperadas pelos outros micro frontends ou a própria aplicação principal.
Tabela 19. Recebimento de evento para reprodução da playlist selecionada
4.5.6. Resultado final
Ao final, todos os fragmentos conseguiram ser executados, independentemente de stack, e exibidos simultaneamente na aplicação contêiner sem a necessidade de instalação de qualquer dependência obrigatória nos micro frontends.
window.RollCake.bus.subscribe('play-user-playback', (context_uri) => { playMusic();
Figura 16. Diversidade tecnológica da aplicação final
Figura 17. Resultado alcançado do protótipo de desenvolvimento do Spotify Clone
5. Discussão
5.1. Cenário de exemplificação funcional com ressalvas
O cenário de exemplificação construído teve uma interface fluida e operacional das funções implementadas pela solução deste trabalho, resultando em uma eficiência comprovada da ferramenta na realização de seus papéis básicos. Apesar disso, houve identificação de algumas ressalvas.
5.1.1. Problemas de SEO
A escolha de utilização de iframes para composição dos micro frontends trouxe consigo uma dificuldade de indexação por sites de buscas como o Google.
5.1.2. Problemas de segurança
Mais um problema causado pela escolha do mecanismo de composição. Os iframes já foram abordados por diversos estudos como um risco de vulnerabilidade crítica para projetos, principalmente quando citado sob ataques de frame hijacking e clickjacking. Porém, os navegadores vêm investindo uma grande quantidade de recursos que objetivam sanar essas deficiências com o tempo e um exemplo disso é o surgimento no HTML 5 do iframe sandbox (o qual foi utilizado neste projeto), navigation policies e o same origin policy (SOP) de forma a dificultar a existência desse tipo de risco [15].
É importante citar que testes de ataques de vulnerabilidade de segurança não foram executados no projeto. Portanto, esse é apenas um item de sobreaviso.
5.2. Migração de sistemas legados
A segmentação arquitetural da solução em diversos módulos provê uma possibilidade de utilização da ferramenta para a migração de sistemas legados em dois cenários:
● Meio para modernização de tecnologia , exemplo: migração de uma aplicação frontend de ASP.NET Web Forms para uma nova aplicação em React.js.
● Meio para mudança arquitetural , exemplo: migração de uma aplicação frontend de ASP.NET Web Forms para uma nova aplicação com arquitetura de micro frontends e segmentando seu conteúdo por contextos de negócio.
5.2.1. Meio para modernização de tecnologia
Para utilização da ferramenta como um meio para a modernização de tecnologia de um projeto legado vê-se necessário a instalação e configuração do módulo mf-broker no ambiente final de utilização, além de algumas poucas adições de código JavaScript na antiga aplicação.
Imaginando uma aplicação monolítica legada construida em ASP.NET Web Forms que deseje segmentar e modernizar suas verticais de desenvolvimento (frontend e backend), as primeiras tarefas a serem executadas para a migração do frontend são relacionadas a criação e configuração de um novo projeto que utilize uma ferramenta moderna de construção de interfaces, por exemplo React.js, e o desenvolvimento dos artefatos de reuso do sistema (header, menu e footer).
Uma vez que as tarefas iniciais estejam concluídas, é feita a instalação da dependência “@rollcakejs/rollcake-mf-broker”, realizada uma importação e declaração da classe “RollCakeMFBroker”, e em sequência segue-se com os passos exemplificados nas tabelas 1 e 2 da seção 4.1. Contudo, a declaração do atributo “address” de cada “bucket” deverá partir de um endereçamento de página específico que defina uma segmentação de contexto de negócio da aplicação legado.
Figura 19. Exemplo de segmentação por contexto de negócio e declaração de variáveis
Realizada a declaração e segmentação dos contextos de negócio de cada micro frontend, o usuário deverá, para cada contexto de negócio identificado, criar uma página e rota com as tecnologias de construção de UI providas pela ferramenta escolhida. Logo em seguida, deverá ir aos arquivos de criação e renderização de componentes e realizar a declaração de um elemento com a tag “rollcake-microfrontend”. Essa tag deverá conter um atributo “name” preenchido com um valor idêntico a um dos segmento de contexto de negócio que foram declarados no parágrafo anterior, assim como exemplificado na Tabela 3 da seção 4.1.
Uma vez que esteja funcionando a exibição, é hora de remover os artefatos de reuso do sistema antigo, afinal já foram portados para a nova ferramenta, e utilizar os serviços da interface de comunicação e dos dados compartilháveis disponibilizados pela variável de janela “RollCake” exemplificados na Tabela 4 da seção 4.1.
Ao final, o usuário terá um portal em React.js suportando um ambiente temporário com a arquitetura de micro frontends que possibilita a escrita de novas funcionalidades ou reescrita de antigas, e a coexistência da versão legado (pelo menos enquanto a aplicação não for totalmente reescrita).
5.2.2. Meio para mudança arquitetural
Para a utilização da ferramenta como um meio de mudança arquitetura de um projeto legado existem quatro possíveis cenários:
● Utilização do @rollcakejs/rollcake-spa como aplicação contêiner e considerando organização de repositório como mono-repositório;
● Utilização do @rollcakejs/rollcake-spa como aplicação contêiner e considerando organização de repositório como multi-repositórios;
● Utilização de uma biblioteca de construção de UI qualquer como aplicação contêiner auxiliado pelo @rollcakejs/rollcake-mf-broker e organização de repositório como mono-repositório;
● Utilização de uma biblioteca de construção de UI qualquer como aplicação contêiner auxiliado pelo @rollcakejs/rollcake-mf-broker e organização de repositório como multi-repositórios;
Cada abordagem irá variar a depender das necessidades de cada projeto de desenvolvimento. Portanto, para um cenário de exemplificação hipotético será abordado apenas o primeiro caso o qual deve ser considerado o caminho mais curto para alcançar o objetivo desta seção.
Em um ambiente em que se deseja utilizar o @rollcakejs/rollcake-spa como aplicação contêiner e uma arquitetura de repositório organizado como um todo (mono-repositório), basta utilizar o template de inicialização de projetos localizado no repositório rollcake-spa-template.
A partir da transferência e instalação de dependências do template anteriormente mencionado, o usuário deverá executar o desenvolvimento dos artefatos de reuso (header, menu e footer) seguindo de exemplo a construção de componentes encontrados na Tabela 10 da seção 4.3.
Uma vez que os componentes estejam prontos, o usuário deverá ir ao arquivo mf-broker.config.js e realizar o mesmo passo-a-passo da seção 5.2.1, a qual refere-se a declaração e segmentação dos contextos de negócio de cada micro frontend da aplicação legado.
Logo em seguida, para cada contexto de negócio deverá ser criada uma página e para cada página uma nova rota no arquivo router.config.js. Dentro de cada página deverá ser realizada a declaração de um elemento de micro frontend. A criação de páginas pode ser vista na Tabela 9 da seção 4.3 e a configuração de rota na Tabela 5 da seção 4.2.
Assim como a seção 5.2.1, uma vez que a exibição da aplicação legado esteja funcionando, remova os artefatos de reuso do sistema antigo e utilize os serviços da interface de comunicação e dos dados compartilháveis disponibilizados pela variável de janela “RollCake”.
Ao final, o usuário terá um portal de SPA construído sob utilização do rollcake-spa suportando um ambiente com a arquitetura de micro frontends que disponibiliza ao usuário a possibilidade de escrita de novas funcionalidades com suporte a diferentes tecnologias, modernização de antigas ferramentas e coexistência com a versão legado.
6. Conclusão e direções futuras
Esse trabalho forneceu o desenvolvimento de uma solução para abstração do processo de integração de micro frontends que pretendia resolver a dificuldade de suporte às tecnologias legadas e os demasiados processos de configuração apontados no single-spa. Os resultados mostraram uma conclusão satisfatória com o desenvolvimento de um protótipo de interface de programação de aplicativos (API) em JavaScript. Foi possível atingir os objetivos esperados, obtendo um produto que cumpre os papéis básicos definidos pela arquitetura em tema e que alcançou, a partir da utilização de uma técnica de composição com auxílio de iframes e uma interface de compartilhamento auxiliada por variáveis de janela, um maior suporte às tecnologias de frontend e facilitação do processo de configuração nos projetos dos fragmentos. Por outro lado, possui pontos de ressalva que podem tornar sua utilização pouco atrativa em um ambiente de desenvolvimento real que deseje realizar uma grande estratégia de marketing digital ou que tenha um alto rigor de segurança, sendo mais recomendado para soluções que visem construir e que desejem realizar um processo de migração de uma aplicação legado.
Dado esse contexto, há uma oportunidade para estudos e melhorias dessa ferramenta em trabalhos futuros. Mais especificamente, há possibilidade para rever o método de composição dos micro frontends (a), refatorar algoritmos de renderização (b), investigar ou revisar vulnerabilidades nos iframes (c) e, até mesmo, estruturar uma solução que consiga ajudar sistemas de busca a entender o conteúdo de iframes (d). 7. Referências bibliográficas
[1] Caifang Yang et al. “Research and Application of micro frontends”. IOP Conference Series Materials Science and Engineering. 2019.
[2] Dragoni, Nicola, et al. "Microservices: yesterday, today, and tomorrow." Present and ulterior software engineering. Springer, Cham. 2017.
[3] KALSKE, Miika et al. Transforming monolithic architecture towards microservice architecture. 2018.
[4] Pavlenko, Andrey, et al. "micro frontends: application of microservices to web front-ends." Journal of Internet Services and Information Security (JISIS). 2020. [5] Newman, S., Building microservices. O’Reilly Media, Inc., 2015.
[6] Cam, Jackson. Micro Frontends. Outubro, 2020. Disponível em: <https://martinfowler.com/articles/micro-frontends.html>. [7] Canopy, single-spa. Acesso em: 27/10/20. Disponível em:
<https://single-spa.js.org/>.
[8] Bastos, João Pedro da Silva. Desenvolvimento Web Orientado a micro frontends. Diss. 2020.
[9] Peltonen, Severi, Luca Mezzalira, and Davide Taibi. Motivations, Benefits, and Issues for Adopting micro frontends: A Multivocal Literature Review. 2020. [10] Luca Mezzalira, increment. micro frontends in context. Acesso em: 27/10/20.
Disponível em: <https://single-spa.js.org/>.
[11] Evan You, Vue.js. Acesso em: 08/09/20. Disponível em: <https://vuejs.org/>. [12] Google, Angular. Acesso em: 27/10/20. Disponível em: <https://angular.io/>. [13] Facebook Inc., React. Acesso em: 27/10/20. Disponível em:
<https://pt-br.reactjs.org/>.
[14] Svelte, Svelte. Acesso em: 27/10/20. Disponível em: <https://svelte.dev/>. [15] Stefano Calzavara, et al. A tale of two headers: a formal analysis of inconsistent
click-jacking protection on the Web. USENIX Security. USENIX Association, 2020. [16] Sooel Son and Vitaly Shmatikov. The postman always rings twice: Attacking and
defending postmessage in HTML5 websites. NDSS. The Internet Society, 2013. [17] Wang, Daojiang, et al. “A Novel Application of Educational Management
Information System Based on Micro Frontends.” Procedia Computer Science, 2020. [18] Zhu, Bin Benjamin, et al. "Component-oriented architecture for web mashups."
2015.
[19] Kalske, Miika. "Transforming monolithic architecture towards microservice architecture." 2018.
[20] Nascimento C. H. P., Eder C. S. S. "MICROFRONTEND: um estudo sobre o conceito e aplicação no frontend." Revista Interface Tecnológica, 2020.
Wrapper renderização de elementos e micro frontends via iframe, e roteamento de página.
prazo, devido a estrutura monolítica.
Atomic
Criação de um módulo responsável pela
renderização de elementos e micro frontends via web components extensíveis de iframes, e roteamento de página. Porém, com uma arquitetura de construção de elementos voltada para o Atomic Design.
1. Difícil manutenibilidade a longo prazo, devido a estrutura monolítica;
2. Arquitetura de componentização (Atomic Design) não muito utilizado e conhecido pelos desenvolvedores frontend, assim dificultando a aderência.
Mimic
Criação de um módulo responsável pela inserção de micro frontends utilizando web components extensíveis de divs com lógica redefinida para apresentação de comportamento similar aos iframes.
1. Solução muito simples e abrangente, assim não iria abstrair tanto o processo como o desejado;
2. Tempo hábil para construção da custom tag similar ao
comportamento de um iframe com mesma facilidade de suporte.
