Desvendando a magia do Server-Side Rendering com NextJS

Você conhece os métodos mais comuns de rendering que temos hoje? Conhece as siglas SSG, SSR e CSR? Sabe como o server-side Rendering funciona? Conhece o ReactJS, mas ainda não conhece Next.js? Se você quer saber mais sobre esse mundo de renderização, fica neste artigo que vamos comentar sobre tudo isso! 😉

No início de tudo, quando ainda não tínhamos o JS (javascript), isso aqui era tudo mato 🌿🌿🌿. Em uma época em que não se falava em arquitetura de componentização, o conceito de injeção de dados nas páginas HTML não era tão comum. O modo de renderização era simples, criávamos nosso arquivo HTML com o CSS e colocávamos em um servidor FTP (Protocolo de Transferência de Arquivos), o que significa que o usuário acessava o seu site e baixava seu arquivo para visualizar o conteúdo no browser. Nesse contexto, temos 2 vantagens:

• A velocidade era extremamente rápida, pois o arquivo baixado era simples. Todas as ferramentas de interpretação já estavam no browser.
• Era muito fácil para o SEO conseguir localizar e ranquear seu site.

Porém, a grande desvantagem foi um dos motivos das mudanças no paradigma de desenvolvimento web, pois TODO O CONTEÚDO ESCRITO está no arquivo, então qualquer alteração precisava passar pelo processo de build e deploy novamente. Esse método de renderização também é conhecido como Static Site Generation (SSG).

A necessidade de querer fazer sites cujos dados mudam com bastante frequência como blogs, sites de notícias e etc, trouxe a criação do método de renderização chamado server-side rendering (SSR). Server-side rendering nada mais é que hospedar uma aplicação em seu servidor e, quando recebe uma requisição, ela busca dados em algum servidor, compila e injeta em um HTML para servir ao cliente, sendo uma opção ótima para o SEO. Diferente do método de SSG, agora temos um paradigma dinâmico. Usado por grandes frameworks como onrails, SSR tinha um grande desafio para época que foi idealizado:

• Não tínhamos grandes recursos computacionais de hardwares para os servidores;
• Não tínhamos grandes aplicações do conceito de computação distribuída como temos hoje.

Isso impactou na grande desvantagem desse modelo na época, pois essas limitações tornavam tudo mais lento. Dentro dessas limitações, enfrentamos o desafio geográfico de servidores que não estavam próximos uns dos outros. Essa distância entre os servidores muitas vezes se assemelhava a uma roadtrip virtual, resultando em atrasos na transferência de dados e um desempenho geral mais lento.

Superar esse problema geográfico se tornou uma prioridade, e soluções inovadoras foram desenvolvidas para mitigar os efeitos das distâncias consideráveis entre os pontos de servidores.

Client-side rendering (CSR) veio como resposta, que explora o conceito do nosso tão amado React. Nesse método de renderização, basicamente tudo acontece do lado do client: enviamos um html simples e todas as informações que ele precisa; depois, um processo de build constrói as pastas do webpack; por fim, quando chega no cliente, o browser pega todas essas informações e “hidrata” o html simples, criando as aplicações que fazemos hoje. Dessa forma, ganhamos muito mais velocidade que o modelo de SSR na época de sua criação, mas, como nada é perfeito, perdemos muita força no SEO. O crawler passa a ter muitas dificuldades em ler o seu site, já que ele é renderizado do lado do client.

Neste ano (2023), o React atualizou sua documentação para indicar três frameworks diferentes para usar ao iniciar um projeto em React. Todos utilizam o React como base, mas buscam resolver problemas que o CSR possui. Os três frameworks que se tornaram referência no mundo de desenvolvimento web por trazerem soluções SSR foram justamente os que hoje estão sendo indicados na documentação atual do React: Next.js, Remix e Gatsby.

Agora que já conhecemos os três principais métodos de renderização, vamos explorar um pouco da prática com o Next.

Next tem como mantenedora Vercel, considerada um dos grandes “hubs” de deploy hoje (onde você consegue fazer deploys de vários frameworks), empresa que se destacou muito nos últimos anos e conquistou grande credibilidade no mercado, nos dando confiança em utilizar o framework Next e, consequentemente, alcançando várias empresas grandes que agora utilizam o Next como framework em seus portfólios. Um ponto de destaque: atualmente, o Next possui uma parceria com o React, o que faz que qualquer atualização seja lançada no Next logo em seguida. Recentemente, tivemos o exemplo do “server components”, incorporado pelo Next em um intervalo de menos de um mês após a atualização do React.

Vamos diferenciar o SSR do Next na prática? Primeiro, um exemplo de como faríamos uma página para renderizar os alunos de uma turma no modelo CSR do React:

import Header from '../components';
import Cardfrom from '../components';
import Loading from '../components';

function CardList() {
  const [students, setStudents] = useState()
  
  useEffect(() => {
    fetch({urlAPI}).then(response => {
      setStudents(response)
    })
  
  }, [])

  if(!students) return <Loading />

  return (
    <div>
      <Header />
      {
        students.map(student => <Card student={student} />
      }
    </div>
  )

}

export default CardList;

Note que precisamos nos preocupar com alguns detalhes de renderização para cobrir casos de erro, de loading e de que a API poderia retornar para nós apenas um array vazio.

Vamos ver como fica a mesma situação utilizando o SSR do Next:

const getStudent = async () => {
  const res = await fetch({urlApi});
  return res.json()
}

export default async function CardList() {
  const students = await getStudents()

  if (!students|| students.length === 0) {
    return (
      <div>
        Não temos estudantes cadastrados
      </div>
    )
  }
  
  return (
      <div>
        <Header />
        {
          students.map(student => <Card student={student} />
        }
      </div>
    )

}

No exemplo acima, vemos um componente server-side, então considere o getStudent rode do lado do servidor, o que deixa tudo mais fácil para lidar com a informação dentro do componente funcional, de fato, abstraindo até a necessidade de um useEffect.

Com esse exemplo, podemos imaginar diversas possibilidades de consumir APIs de forma server-side e até aproximar mais o backend do frontend (mas isso já é assunto para um outro artigo 😉). Um ponto de observação muito interessante é o fato de que o que roda server-side não fica visível para o cliente, então, dependendo da informação que estamos lidando, também pode ser uma forma de melhorar a segurança do seu código e suas APIS.

Em um mundo em constante evolução do desenvolvimento web, exploramos os métodos de renderização — SSG, SSR e CSR. Com a chegada do Next.js e Remix, as soluções SSR se tornaram mais acessíveis e promissoras do que nunca. À medida que continuamos nossa jornada, aprimorar essas habilidades e abraçar a mudança é fundamental. O futuro da web está em constante evolução, e nós, como pessoas desenvolvedoras, evoluímos junto com ele. 🚀🌐

Agora é com você! Você já usou/conhecia os três métodos de renderização que exploramos neste artigo? Já conhecia o Next.js? Como foi a sua experiência com ele? Deu vontade de usar? Deixa nos comentários!

🤞🤞🤞