Server Side Rendering, Single Page Application, Static Site Generation, Incremental Static Regeneration e Next.js (pt. 1)

Em cada canto do ringue, uma técnica de renderização de peso (e algumas menos pesadas).

Fala, galera! Aqui é o Professor Ricardo Pedroni e vamos juntos para mais uma aula fantástica 🎉
🎥 Não esqueça de ver essa aula e muitas outras no nosso Canal do YouTube!

Nos primórdios da internet, quando os homens da caverna usavam pedras e palha para começar fogos, páginas com apenas HTML e CSS eram comuns e PHP era considerado uma tecnologia válida de ser usada por pessoas sãs, a rede era composta basicamente pelo modelo cliente-servidor.

Nessa época, um site era constituído basicamente de informações estáticas e designs nada-estáticos (Deus abençoe a alma de quem deixou o site original do Space Jam vivo até hoje), onde uma página era basicamente um arquivo HTML com uma pitada (pesada) de CSS cabuloso para decorar os botões que giram e os fundos que piscam. Mesmo com todo esse movimento e a possibilidade de iniciar uma crise de convulsão, o importante é que essas páginas não precisavam puxar informações de fontes externas e atualizar seus dados frequentemente.

“Sim, Rodrigo, é fundamental que o fundo pisque e TOQUE MÚSICA QUANDO O USUÁRIO ENTRAR E QUE ELE NÃO TENHA OPÇÃO DE DESLIGAR ELA PÔRRA”

Dessa maneira, uma vez que você escrevesse o HTML do seu site, bem.. ele estava pronto. Para toda a eternidade (vide o site do Space Jam — Deus realmente abençoe essa pessoa que deixou esse site no ar).

Então era natural que o modelo predominante de serviço web na época fosse o tradicional cliente-servidor, onde um cliente (e.g. um browser) pede um recurso (e.g. uma página localizada num endereço específico) e o servidor, aprovando esse pedido, devolve esse recurso. E quando esse recurso é algo completamente estático como eram os sites na época, o que o servidor devolvia era exatamente o recurso pedido — i.e. a página do site em questão (inclusive, veja no site do Space Jam que a maioria das páginas termina com .html, significando que o que você recebeu é realmente o próprio arquivo HTML).

Usando a linguagem de conversa altamente técnica e formal entre cliente e servidor.

Um arquivo estático pode ser visto abaixo

Talvez até roubado de spacejam.com

Repare que num arquivo estático, todas as informações necessárias já estão presentes no próprio documento, significando que o mesmo está pronto para ser enviado a qualquer cliente que pedir.

E por muitos anos, tudo estava bem no mundo da internet, onde os documentos e a troca de informação reinavam…

Web 2.0 (ou “Como a humanidade se perdeu”)

O modelo de entregar um documento “pronto” para os clientes fez sentido por muito tempo mas com o passar dos anos, a internet começou a virar algo muito mais dinâmico, responsivo e voltado aos usuários e às pessoas (e os gatos) invés de documentos e mera troca de informação.

Com sites como Tumblr, Blogger, Twitter e qualquer startup cujo nome foi gerado colocando um “r” e comendo umas vogais pode te dizer, o foco dessa nova web é personalização e criação, onde cada usuário de um site ou uma “rede” gera conteúdo e as informações mudam rapidamente.

Um leitor mais sagaz pode ter reparado que, por mais que documentos estáticos fornecem repostas rápidas (“tá tudo pronto de antemão”), um arquivo estático carece de personalização. Enquanto teoricamente possível, se minha rede social tem 100 mil usuários, não é muito eficiente gerar uma página de perfil estática para cada um deles, além do que que geralmente numa rede dessas, as informações estão mudando o tempo todo (pense na página principal do Facebook e como ela era dinâmica quando você acessou ela pela última vez 4 anos atrás).

Com essa nova web, não era mais possível ter todas as informações prontas de antemão. Por mais que ainda era responsabilidade dos servidores devolverem os documentos aos clientes, invés de devolver um arquivo pronto estático, os documentos começaram a ser renderizados do lado do servidor. Na prática, isso significa apenas que o documento devolvido em partes era estático mas continha alguma informação que o servidor colocou ali, justamente na hora que foi feito o pedido por aquele documento.

Em apenas 7 dias?!

Um exemplo de um documento que pode ser gerado pelo servidor tá aí:

Nessa época, apareceram ou subiram em popularidade as linguagens de script, como PHP e Ruby (e alguns anos depois, o Node), que serviam como linguagens de backend, capazes de rodarem em servidores, podendo conectar com banco de dados, fazer chamadas à API externas e renderizar páginas com essas informações, devolvendo ao cliente um documento que fosse personalizado para ele.

Dói menos quando não sabemos.

Repare que o que o cliente recebe é um documento “pronto”, igual ao estático, mas dessa vez com informações customizadas a ele. Essa mágica toda acontece porque o servidor recebe o pedido do cliente, analisa o que ele precisa/quem ele é, e devolve o documento com informações que o próprio servidor puxou de algum lugar (e.g. um banco de dados). A técnica onde o documento é renderizado do “lado do servidor” se chama Server Side Rendering (SSR).

Essa mágica toda, porém, vem com um custo — o servidor demora mais tempo agora para devolver a página, já que precisa buscar as informações para ser montada (e caso o servidor não for configurado de forma muito eficiente, o servidor vai pegar essas informações em todas as chamadas, mesmo se essa informação adicional não mudar).

Um detalhe interessante sobre como o SSR e como era implementado antigamente é que é muito utilizado para gerar documentos completos, como uma página HTML inteira, que é devolvida completa ao cliente. Isso pode ser útil mas significa que qualquer interação entre o cliente e o servidor requer o pedido de uma página completa, mesmo que boa parte da página atual não mudou.

SSR foi e continua sendo uma técnica de renderização muito utilizada, especialmente para páginas que precisam de customização e que tenham informações constantemente mudando. No entanto, a internet e a forma que a usamos continuou a evoluir, e renderizar e interagir com o servidor dessa forma, fazendo pedidos de páginas inteiras, também se mostrou limitada em alguns casos. Se apenas houvesse uma forma mais dinâmica, modular e assíncrona de interagir com servidores…

Mas falaremos sobre isso na Parte 2 🔥 Aquele abraço e até lá!

Espero que esse post tenha te ajudado!
Ficou com dúvida ou quer mandar uma real? Deixa nos comentários!
Ah, e me acompanhe também no YouTube! ✌

TLDR;

• A internet começou com o model tradicional de cliente-servidor, onde um servidor devolvia um recurso (e.g. página) estático ao cliente;
• Com o avanço da internet, as páginas deixaram de ser estáticas, sendo geradas à base que fossem requisitadas, renderizadas pelo servidor, entregues prontas ao cliente, técnica conhecida como Server Side Rendering (SSR);
• A possibilidade de customizar a resposta e renderizar do lado do servidor vem com o custo da resposta demorar um pouco mais, já que é necessário realizar “ações” adicionais (e.g. ler um banco de dados) para preencher a página;
• SSR antigamente envolvia fazer um pedido toda vez que o cliente fosse interagir com o servidor, requerendo carregar uma página completa toda vez. Talvez exista uma forma melhor de fazer isso…