| path | title | subtitle | date | tags | banner | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
/renderizacao-de-aplicacoes-modernas |
Renderização de aplicações modernas |
No que os conceitos de renderização no cliente, servidor, universal e estática podem te ajudar |
2020-04-28 |
|
|
Estudando atualmente sobre aplicações e abordagens de frameworks/bibliotecas talvez você já tenha lido alguns termos como: server-side rendering, client-side rendering, universal rendering e static rendering.
Uma coisa que todos esses termos tem em comum é justamente o fato de estarem relacionados ao momento e o jeito que uma aplicação é renderizada e todo o processo pelo qual ela passa até estar na tela do usuário final. É sobre essas diferenças que vamos falar um pouco hoje.
Vale lembrar que todas essas abordagens estão diretamente ligadas com a forma que seu navegador (o cliente) e sua aplicação lidam com as requisições ao servidor e possíveis APIs externas. Vamos comentando sobre elas em cada um dos tópicos, ok?
A técnica mais utilizada nos primórdios da web.
Consiste em renderizar uma aplicação exclusivamente no servidor e retornar o conteúdo para o cliente já totalmente pronto, sem necessidade de eventuais consultas a APIs após o carregamento. Se você teve alguma experiência com WordPress, por exemplo, é bem provável que conheça esse tipo de renderização.
Abordagens desse tipo tradicionalmente possuem lógicas de acesso e consulta aos dados de um banco de uma forma diferente das que você pode ter utilizado quando está trabalhando com APIs baseadas em rotas. Embora possa ser organizada e possuir abstrações tão úteis quanto as demais, com o tempo, acabou ficando um pouco de lado devido às questões de separação de responsabilidades do front-end e do back-end, já que, quando utilizadas, acabam deixando o desenvolvimento desses dois cenários um pouco mais entrelaçados (apesar de muitos frameworks lidarem com essas separações de camadas de uma forma bem satisfatória e não deixarem nada a desejar).
Ou seja, essa abordagem é constituida por uma requisição principal, que já traz o conteúdo pronto a ser consumido. Futuramente requisições para outros arquivos estáticos como CSS, JS e imagens deve ocorrer, mas o "corpo" do seu conteúdo já estará pronto para ser consumido.
Tomou bastante visibilidade com todo o crescimento das bibliotecas e frameworks front-end. É uma alternativa mais barata, mas que não traz os benefícios de SEO tão claros e outras vantagens que uma aplicação renderizada no servidor pode trazer.
Outro termo que está ligado com esse tipo de renderização é o tão falado SPA (single-page application). O que esse termo quer dizer é que (em teoria) seu navegador (o cliente) será responsável por carregar a página da sua aplicação uma única vez. Dessa forma, as seguintes mudanças na sua aplicação deve ocorrer de forma mais fluida por meio de atualizações da própria aplicação e requisições que seus scripts deve fazer em APIs externas, fazendo com que seu navegador não tenha o "trabalho" de realizar uma requisição para uma nova página a cada mudança na sua aplicação.
Com a utilização dessas estruturas, as camadas de back-end também começaram a modificar a forma como respondiam às requisições do front-end para que a comunicação fosse mais fácil de ser realizada. Ao longo desse período, termos como web services (serviços web) começam a ser adaptados para APIs (application program interface ou interface de programação de aplicações) ao mesmo tempo em que as requisições para o servidor começam a ser arquitetadas de uma forma diferente (REST e, mais atualmente, GraphQL) tendendo a ter uma resposta em JSON ao invés de XML (como era comumente feito via SOAP anteriormente).
Nessa estrutura de renderização, boa parte da interação do usuário com a interface provavelmente ficará pendente até que o cliente (navegador) termine o download dos arquivos de script e inicie a aplicação de forma correta.
Se aproveita de conceitos da renderização no servidor e também traz algumas novidades e, por isso traz os benefícios já conhecidos de SEO, mas também um custo com infraestrutura para manter uma aplicação rodando em um servidor como é necessário.
Essa estrutura possui a renderização inicial da aplicação no servidor (assim como as mais "tradicionais"). A diferença é que um novo processo ocorre após o conteúdo chegar ao cliente formatado como deveria: a hidratação (ou hydrate).
Essa etapa é algo fundamental para que sua aplicação siga o "fluxo de vida" (e continue executando como o esperado) dela naturalmente. É nesse momento que os frameworks/bibliotecas vão interpretar todo o conteúdo já presente no seu HTML e reiniciar sua aplicação no cliente com esse conteúdo formatado, refazendo os bindings necessários para que as interações via JavaScript funcionem corretamente.
Por isso o nome dessa abordagem é "universal" (mas não se estranhe caso ouça o termo server-side rendering para essa abordagem também), já que o conteúdo que é "iniciado" no servidor, mas segue um fluxo de vida que faz com que a aplicação execute no cliente mantendo uma única tecnologia permeando os cenários do back-end e front-end.
Geralmente pode ser feita com as APIs do próprio framework/biblioteca (como é o caso do React) mas também existem outras abtrações e frameworks que podem facilitar seu trabalho e reduzir a quantidade de configurações manuais que você precisará desenvolver (como é o caso do Next, que permite que você trabalhe com o React utilizando essa abordagem).
Provavelmente a abordagem mais performática e com menor custo de todas as que temos, entretanto, demanda alguns trabalhos extras caso queira integrar com algum tipo de atualização ou incremento de informações (como um CMS ou alguma fonte de dado externa).
Essa estratégia utiliza algumas táticas de renderização no servidor para, ao fim de um processamento (geralmente chamado de build), gerar um conteúdo exclusivamente estático. Isso faz com que você não precise de uma aplicação rodando em um servidor e também que a performance do seu sistema/site tenha um aumento considerável junto com um custo bem reduzido, já que você não precisará de um servidor para interpretar alguma informação dinâmica e muitos provedores hoje em dia oferecem hospedagem de conteúdo estático de forma gratuita.
Nessa abordagem, as ferramentas tendem a produzir esse conteúdo estático já otimizado necessitando o mínimo de configuração possível. O cliente fica responsável somente por realizar a requisição para o servidor que, consequentemente, já retornará o arquivo pronto a ser consumido. Nesses arquivos estáticos também está todo o conteúdo responsável por prosseguir com o estado e o fluxo da sua aplicação após o consumo do cliente, sendo uma alternativa parecida tanto com a renderização no servidor quanto no cliente (por precisar passar por esse processamento de arquivos em uma máquina mas também por seguir com sua execução normalmente seguindo a tecnologia escolhida).
Dessa forma, você consegue escrever sua aplicação com a tecnologia que for mais conveniente (no caso do React, temos o Gatsby e até mesmo o próprio Next como as opções mais conhecidas atualmente), mas ter um conteúdo final totalmente estático. O processo de build serve para que uma máquina (até mesmo seu computador pessoal) interprete suas configurações e preferências da aplicação e produza todo o conteúdo final, que você simplesmente precisará hospedar em algum lugar.
Quais experiências você teve com essas diferenças de renderização? O que achou de cada uma delas? Tem alguma favorita?
Espero que tenha gostado do post e que possa te ajudar caso esteja pensando em escolher uma nova abordagem para seu sistema/site!
Caso queira ver um conteúdo bem bacana sobre renderizações de aplicação, com animações, o Franck Abgrall tem um post bem bacana que serviu de inspiração pra boa parte do conteúdo que escrevi aqui, com certeza você vai curtir!