Server Side Rendering, Single Page Application, Static Site Generation, Incremental Static Regeneration e Next.js (pt. 2)
Renderizando como se não houvesse amanhã.
Essa aula faz parte de uma série então veja a Parte #1 se quiser começar do começo.
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!
Terminamos a aula passada discutindo sobre o Server Side Rendering (SSR) e como essa técnica nos habilitou a termos uma internet mais dinâmica e personalizada, uma vez que páginas poderiam ser geradas a medida que fossem requisitadas. Com isso em mente, vamos nos ambientar melhor em como o modelo cliente-servidor funcionava na época.
Independentemente se estamos falando de SSR ou páginas estáticas, tipicamente a interação entre um cliente e um servidor seguia o modelo:
- Cliente: me dê o documento localizado em site.com/meu-perfil
- Servidor: deixa eu ver eu tenho esse documento… tenho sim, toma aqui.
- Cliente: obrigado, servidor. (opcional, apenas browsers educados)
Além dessa sequência altamente técnica de troca de mensagens, repare que até agora, sempre falamos na troca ou requisição de páginas e documentos. Isso foi intencional porque nessa época, o conceito de troca de informação ainda era à base de troca de documentos inteiros e isso não é a toa — todo o início da internet foi fundamentado nessa troca de documentos.
Mas é importante destacar que esse modelo de documentos inteiros fazia muito sentido quando a internet era uma ferramenta de pouca criação e muita leitura. Como falamos na aula passada, a partir do momento que “evoluímos” para a Web 2.0 e toda a dinâmica e velocidade que ela trouxe e precisava, esse modelo começou a apresentar alguns problemas.
Veja bem — agora não somos mais meros leitores e espectadores dos documentos alheios, agora somos criadores e geramos posts envolventes e tweets sobre quantas fatias de presunto colocamos no sanduíche que acabamos de comer.
Nessa era de geração de conteúdo, uma interação entre cliente e servidor para criar um conta de usuário numa plataforma poderia ser assim:
Num modelo predominantemente baseado na troca de documentos, qualquer interação entre um cliente e um servidor precisa receber e enviar documentos inteiros para que essa troca possa ocorrer. Apesar de funcionar, isso torna a experiência de usuário (famosa ú·xis) precária, uma vez que seu usuário pode ficar segundos esperando com uma tela vazia enquanto o servidor carrega ou processa alguma informação.
…e por muitos anos, fazer o quê, era o jeito de se fazer a internet 🤷♀️
Mas no começo dos anos 2000, com o crescimento i̶n̶c̶e̶s̶s̶a̶n̶t̶e̶ contínuo de plataformas sociais, outros meios de criação de conteúdo e a necessidade de nos aproximarmos mais de experiências rápidas e em tempo real, desenvolvedores se viram com a necessidade de sanar esse problema de troca de documentos inteiros… e eis que uma tecnologia nasceu.
Apelidado de AJAX (Asynchronous JavaScript and XML), essa tecnologia permitia que clientes e servidores pudessem conversar de forma assíncrona (i.e. sem precisar sincronamente trocar um documento/carregar uma página inteira) usando JavaScript para fazer essas chamadas e o servidor respondendo com dados invés de documentos, tipicamente usando o formato XML.
Vou fazer uma pausa aqui para explicar uma coisa — se você não estava trabalhando ou envolvido na área web nessa época, você provavelmente nunca ouviu esse termo e talvez nem sabia que um dia a web não trabalhava com chamadas assíncronas — mas deixa eu te explicar uma coisa: para qualquer um envolvido na comunidade na época, AJAX foi revolucionário.
AJAX talvez seja uma das siglas mais fadadas a parecer velha logo de cara porque XML era uma linguagem de markup bastante utilizadas na época mas que perdeu espaço rapidamente para JSON como um formato de troca de dados.
Pausa #2: Você já se perguntou alguma vez porque que no DevTools do browser existe o filtro “XHR” na aba de Network? Ou por que que o JavaScript tem um método chamado de XML Http Request (eis o XHR)? A resposta é porque tudo isso começou com o singelo uso do XML e o nome acabou ficando.
Com essa tecnologia revolucionária, agora era possível um cliente e servidor se comunicarem sem ter que trocar um documento completou ou carregar uma página nova. No exemplo da criação de conta, basta agora o cliente mandar as informações do formulário e o servidor pode responder com os dados, se deu certo ou não, etc., e o browser pode agir de acordo — inclusive, isso abriu a porta para páginas “em tempo real”, como cotações de valores, resultados e números que mudam constantemente (inclusive servindo como base para anos depois o aparecimento dos websockets e seu modelo push).
Como agora o cliente poderia executar mais coisas do lado dele (e as máquinas dos clientes estavam ficando mais poderosas), as responsabilidades e funcionalidades client-side começaram a aumentar. Foi nessa época que o conceito de “Servidores APIs” começou a se fortalecer, com servidores que já não devolviam mais páginas ou documentos mas apenas informação, com um esquema de URLs estruturada seguindo alguma lógica (eis nosso amigo REST ganhando força), devolvendo essa informação tipicamente usando XML ou JSON.
Devido ao fato do cliente agora ter tantas possibilidades, cada vez mais criamos aplicações complexas do lado dele, indo ao ponto de criarmos aplicações inteiras que vivem apenas do lado do cliente, com o servidor servindo apenas para devolver o documento original e responder com dados, quando o cliente pedir esses dados dele.
Nesse esforço de termos clientes robustos, nasce o que hoje chamamos de Single Page Application (SPA). Mais uma vez, o nome é bastante pertinente. SPAs são documentos mínimos (i.e. tem a menor quantidade de informação possível de início) e que podem então ser puxados rapidamente do servidor. Uma vez no cliente, é papel do JavaScript montar toda a estrutura e conectar dados com interface, criando efetivamente o que você vê e com o que você interage.
Quando criamos um app usando o Create React App, o que é criado é um SPA, e o único documento que existe é o index.html e sua “aplicação inteira” se resume a:
O segredo em SPAs é que vai existir uma forma do JavaScript interagir com o documento e, a partir dele, criar toda a estrutura do app (no caso do React, normalmente é o <div id="root"> )
SPAs são leves, rápidos de baixar e tipicamente fornecem uma boa experiência de usuário se programados corretamente. Mas como toda coisa boa, tem coisa não tão boa assim também.
Se sua aplicação se importa com SEO (lembrando que nem todo app vai se importar com isso, como painéis admin ou qualquer parte da sua aplicação atrás de um login), SPAs podem ser detrimentais, uma vez que os crawlers de SEO vão enxergar uma página praticamente vazia e sem conteúdo (vide nosso código acima ali). Outro potencial problema é que se criado de forma ingênua, um SPA pode forçar o cliente a baixar a aplicação inteira, mesmo partes dela que ele nunca vai usar ou acessar, visto que não existem URLs ou documentos explícitos. Ambos esses problemas podem ser resolvidos mas nem sempre é trivial trazer essas otimizações dependendo como sua aplicação foi programada. Então antes de sair fazendo um SPA em React ou Angular (ou JS puro se você for insano), dê uma pensada nessas consequências.
E eis que na nossa caminha pela história da web, temos ferramentas agora para gerar aplicações mais dinâmicas, com o uso ainda de documentos inteiros ou apenas partes deles, usando AJAX e, caso queiramos fazer uma aplicação inteira client-side, SPA.
Mas nessa busca constante de melhorarmos a experiência dos usuários e dos desenvolvedores, começou-se a sentir falta de uma forma de gerar páginas e documentos completos e prontos. E começou-se a hipotetizar: “Imagina que legal se tivéssemos uma forma de ter os documentos já prontos no lado do servidor e que, bastasse o cliente pedir por eles, eles receberiam esse documento pronto imediatamente, sem quer o servidor precisasse gerar eles? Imagina se pudéssemos trabalhar com documentos… estáticos”
E como a moda se repete, também se repete a tecnologia — falaremos sobre documentos e geração estática na aula que vem ~ 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;
- O funcionamento original do modelo cliente-servidor era à base de troca de documentos e páginas completas;
- Esse funcionamento trazia uma experiência mediocre, uma vez que qualquer interação, por menor que fosse, requeria que o servidor enviasse um documento completo novo;
- AJAX apareceu como uma solução para pedidos assíncrono de informação;
- Baseado nesses pedidos assíncronos, aplicações inteiras foram criadas do lado do cliente (client-side), chamadas de Single Page Applications (SPA), devido ao fato de tipicamente serem uma única página/documento;
- SPA são tipicamente leves e rápidos mas podem ser uma solução medíocre se sua aplicação necessita de alguns fatores, como SEO.
