O poder dos Micro-Frontends: Introdução a SSR, CSR e IR

O que é Client Side Rendering – CSR?

Client-side rendering (CSR) é uma técnica para servir páginas web onde a renderização ocorre no lado do cliente, ou seja, o processo de renderização ocorre no navegador do usuário usando JavaScript. No CSR, o servidor envia o HTML inicial, CSS e arquivos JavaScript para o cliente, e o navegador executa o código JavaScript para buscar dados de APIs e renderizar o conteúdo dinamicamente. SPA, Single Page Application e um dos conseitos que estão na categoria CSR.

Figura 1 – Arquétipo de CSR

CSR tem uma relação maior com o desenvolvimento web moderno, nos dando alguns benefícios claros.  exemplos:

• Atualizações de conteúdo sem recarregar a página inteira. Com frameworks Javascript como React, Vue.js e Angular, os desenvolvedores podem manipular o Document Object Model – DOM e atualizar componentes específicos com base em interações do usuário ou alterações de dados, proporcionando uma experiência perfeita e interativa por exemplo em validações de formulários, resultados de busca instantâneos ou até mesmo chat em tempo real.
• Facilita o reuso de código, conforme discutido . Quando pensamos nosso front pensando em componentes, estamos abordando Micro-Frontend em uma das esferas, que é a componentização, já que ao invés de pensar em páginas inteiras, pensamos em botões, modais de alerta, grids, carrosséis ou até mesmo em uma abstração ainda maior, como um modulo de busca, ou uma estrutura de repetição utilizado por blocos de imagem e texto. Adotando essa estrutura de componentes modulares, podemos criar micro-frontends relevantes para nosso negócio, por exemplo: uma aplicação com Dashboards e ferramentas de análise – os aplicativos de painel e análise podem utilizar Micro Frontends para desenvolver módulos separados para visualização de dados, relatórios, gerenciamento de usuários e definições de configuração. Cada módulo pode ter seu próprio ciclo de vida de desenvolvimento, permitindo melhorias direcionadas e integração perfeita em um painel unificado ou plataforma de análise.

Algumas considerações devem ser tomadas para adotar CSR’s:

• Otimização do SEO – Search Engine Optimization – é um problema. O tamanho do payload, também pode ser grande. Visto que há muitos requests que são feitos a cada carregamento de componente, essas negociações de protocolos HTTP são feitas múltiplas vezes o que pode acarretar um tamanho maior de download e afetar conexões mais lentas e instáveis.
• CSR’s são fortemente dependentes do Javascript e suas bibliotecas. A curva de aprendizado para cada uma delas é diferente e encontrar pessoal especializado em cada uma delas é um desafio a parte. Além disso é necessário pensar em um mecanismo de degradação mais gracioso. Uma vez que CSR é fortemente dependente de Javascript e suas bibliotecas, alguns usuários podem não ter uma experiencia positiva se algum desses componentes não forem carregados ou se estiverem com Javascript desabilitado em seus navegadores. Uma maneira de mitigar isso é servir um HTML básico ao encontrar esse comportamento.
• Considerar o uso de Lazy Loading: Lazy Loading refere-se a uma técnica em que ativos, como código JavaScript de determinadas parte da página, imagens ou outros recursos, são carregados somente quando são necessários. Em vez de carregar todos os ativos antecipadamente, o carregamento do tipo lazy load permite um uso mais eficiente dos recursos de rede, adiando o carregamento de conteúdo não crítico até que seja necessário

O que é Server Side Rendering – SSR?

Server Side Rendering (SSR) é uma técnica para servir páginas web, geradas e parcialmente renderizadas no servidor antes de serem enviadas para o cliente (browser). Essa abordagem permite que o servidor processe a URL solicitada, gere dinamicamente o conteúdo HTML e envie a página HTML totalmente renderizada para o cliente, pronta para ser exibida.

Assim, na abordagem SSR, o servidor antes de devolver a resposta para o cliente, o servidor precisa resolver toda a informação, executando API’s ou chamadas em bancos de dados a fim de obter essa informação e depois gerar o HTML. Algumas tecnologias como Node.js com Next, Python com Django, Java com Spring, são frameworks de SSR.

Um ponto positivo para o SSR é que o SEO é resolvido sem muito esforço pelos web-crawlers e buscadores. A relevância para SEO pode ser crucial para alguns websites e facilitar o scan, entregando todo o conteúdo já disponível após a primeira requisição, sem requisições adicionais, permitindo que esse site seja indexável melhorando o ranking dessa página nos buscadores, pois o SSR incluí tags de metadados e dados de forma estruturada ao retornar o HTML completo.

Figura 2 – Arquétipo de SSR

Entretanto, devemos fazer algumas considerações antes de antes de começar a caminhar  em direção a SSR, principalmente quando falamos sobre desempenho, custo e complexidade:

• Desempenho, é necessário entender e testar o tamanho do payload que está retornando na sua página. Um volume alto no payload pode impactar diretamente no tempo desta requisição e isso pode resultar em páginas que são carregadas de forma lenta, prejudicando experiencia de seus usuários.
• Aumento de complexidade, pois pode ser necessário que lógicas de renderização sejam aplicadas ou até mesmo algum tipo de roteamento extra se faça necessário e potencialmente guardar os estados das sessões desses servidores em algum servidor de cache, como o Amazon Elasticache, exemplificado no próximo fluxo.

Figura 3 – Arquétipo SSR Complexo

O time, quando opta por SSR, deve ter em mente esses trade-off’s para que isso não seja uma má decisão para o projeto

O melhor dos dois mundos, tem como?

Sim, e isso tem nome. É chamado de Isomorphic Rendering (IR) – renderização isomórfica – O principal objetivo de um IR é manter uma experiencia boa para o usuário e também deixar o SEO mais otimizado. Em uma aplicação isomórfica, os conceitos de SSR e CSR são aplicados ao mesmo tempo. Onde uma requisição completa é servida pelo servidor Web (SSR) e interações futuras manipulam o DOM via Javascript(CSR). Importante ressaltar que temos que lembrar dos trade-off’s anteriormente mencionados.

Como Abordar isso na AWS?

É possível abordar todos os cenários que falamos na AWS. A AWS oferece uma grande variedade de serviços de computação para abrigar os mais diversos tipos de necessidade para executar arquiteturas de Micro-frontends. Para CSR por exemplo, podemos utilizar o Amazon S3 com a funcionalidade de Web-site estático – Confira nesse exemplo – ou até mesmo o Amazon Amplify. Já para SSR, podemos utilizar desde serviços de computação, seja eles com Amazon EC2, Containers com o Amazon ECS ou Amazon EKS, AWS Fargate ou até mesmo funções Lambdas.

O que está por vir?

Nos próximos posts da série, vamos montar uma aplicação de renderização isomórfica na AWS e utilizar uma serie de abordagens modernas como GraphQL, Lambdas e Api Gateways e module Federation para demonstrar o quão longe podemos ir quando o assunto é Micro-Frontend

Sobre os autores

Kevin Lira é um arquiteto de soluções sênior na AWS, trabalhando na indústria de FSI. Sua experiência profissional anterior inclui desenvolvimento de software, liderança técnica e arquitetura em outras indústrias. Bacharel em Sistemas de Informação e Especialista em Computação Flexível e Tecnologias Microsoft.

Me siga no LinkedIn: https://www.linkedin.com/in/kevinlira/

Jean Rogatis é Arquiteto de soluções sênior na AWS, Trabalhando na indústria de Financial Services . Entusiasta de novas tecnologias, construiu mais de 10 sistemas, de soluções de big data a portais de vendas, entregando um crescimento YoY de três dígitos e liderando uma equipe de 50+ pessoas. Ajuda empresas a transformar seus negócios, adotando tecnologias baseadas em nuvem para encantar seus clientes, parceiros e funcionários.

Me siga no LinkedIn: https://www.linkedin.com/in/jrogatis/