Introdução

Next.js é uma das estruturas React mais importantes e amplamente utilizadas. Hoje, ele se tornou uma estrutura consolidada para a criação de aplicativos da web incríveis.

Muitas vantagens podem ser listadas ao usar Next.js. Desempenho, SEO, rica experiência de desenvolvedor, suporte a TypeScript, smart bundling e pré-busca de rotas são apenas alguns exemplos.

Além de todos os recursos incríveis que Next.js tem a oferecer, há um em particular que é muito poderoso e incrível: a capacidade de usar diferentes técnicas de pré-renderização.

Podemos trabalhar com renderização do lado do servidor (SSR) e geração de site estático (SSG) no mesmo aplicativo Next.js. Também podemos ter nosso aplicativo renderizado do lado do servidor e ainda ter algumas páginas geradas dentro.

Neste artigo, aprenderemos mais sobre como essas duas técnicas de pré-renderização funcionam e como podemos usá-las. Também aprenderemos mais sobre os casos de uso específicos para ambos.

SSR (renderização do lado do servidor)

Os frameworks JavaScript modernos tornaram nossas vidas como desenvolvedores muito mais fáceis. Podemos criar aplicativos da web avançados e ricos usando muitas técnicas de renderização diferentes.

Você provavelmente já ouviu falar de aplicativos de página única antes. Um aplicativo de página única é aquele que é renderizado no lado do cliente, mesmo que os dados possam ser buscados no servidor.

A renderização do lado do servidor (SSR) é exatamente o oposto disso. O SSR descreve o processo de pré-renderizar a página no servidor, que é gerado a cada solicitação do usuário.

Quando a página pré-renderizada chega ao navegador, o código JavaScript é executado para tornar a página interativa. Todo esse processo torna a velocidade de carregamento mais rápida. Também torna mais fácil e preferível usar a renderização do lado do servidor para aplicativos que dependem de SEO.

Next.js faz isso fora da caixa. Por padrão, ele tentará detectar qual técnica de pré-renderização seu aplicativo está usando e buscar seus dados.

Anos atrás, antes que o JavaScript se tornasse tão maduro e poderoso, os desenvolvedores geralmente retornavam arquivos HTML com base em chamadas HTTP. Era uma técnica muito comum processar a resposta no lado do servidor usando uma linguagem do lado do servidor (geralmente PHP) e retornando um arquivo HTML estático.

SSG (geração de site estático)

Os sites gerados estáticos não são novidade para os desenvolvedores. Nós os construímos desde o início da web. Construir experiências ricas na web pode ser difícil, mas com Next.js podemos fazer isso facilmente.

Next.js nos apresentou uma maneira melhor de construir sites de geração estática com desempenho mais dinâmico.

SSG descreve o processo de construção de sites que são renderizados no momento da construção. A saída é um arquivo HTML, recursos como JavaScript e CSS e alguns outros arquivos estáticos.

Ao usar SSG com Next.js, a página é pré-renderizada no momento da compilação. Isso significa que o usuário não terá que esperar a página carregar no navegador; a página será simplesmente renderizada.

Para busca de dados, Next.js oferece três funções diferentes:

• getStaticProps : A página será pré-renderizada no momento da compilação
• getServerSideProps : a página será pré-renderizada no tempo de execução
• getStaticPaths : esta função gera uma lista de páginas que serão pré-renderizadas no momento da construção

A maior desvantagem de usar SSG é que o tempo de construção pode ficar muito longo. Você não terá problemas quando tiver apenas algumas páginas geradas estaticamente, mas conforme seu aplicativo cresce, o tempo de compilação aumenta.

O pior cenário é quando você tem centenas de páginas geradas estaticamente. O tempo de compilação demorará muito e, se você tiver conteúdo dinâmico nessas páginas, poderá acabar com muitas compilações.

Qual devo usar?

Next.js facilita muito a escolha da técnica correta de pré-renderização para cada página.

Lembre-se, aprendemos que Next.js faz a geração de sites estáticos por padrão. Ele simplesmente funciona fora da caixa. No entanto, ele tentará detectar qual método de pré-renderização você está usando para cada página.

Definitivamente, existem alguns casos em que escolher a função certa para buscar seus dados fará a diferença. Deve ser levado em consideração porque pode causar um grande impacto na experiência do usuário.

Imagine que estamos criando um site de blog simples. O conteúdo será totalmente gerado estaticamente, certo? Teremos apenas algumas páginas e o conteúdo será obtido de nosso servidor, portanto, faz todo o sentido usar o SSG neste caso.

Podemos supor que todo blog tem pelo menos duas páginas essenciais:

• posts : esta página é responsável por buscar e exibir todos os posts do blog
• post : esta página é responsável por buscar e exibir uma postagem específica do blog

Em nossa página posts , podemos usar SSG para buscar todos os nossos posts, usando a função getStaticProps :

 exportar função padrão Postagens ({posts}) { Retorna ( 
 
 Minhas últimas postagens 
 {posts.map ((post)=> ( 
 {post.title} 
 ))} 
 );
} exportar função assíncrona getStaticProps () { Retorna { adereços: { posts: await fetchPosts (), } };
}

A função fetchPosts será executada no momento da construção. Ele irá buscar nossos dados externos e pré-renderizar o conteúdo de nossa página.

Agora, imagine que queremos adicionar um pequeno recurso em nosso site de blog simples.

Imagine que somos uma pessoa muito famosa e nossos seguidores querem comprar itens de nossa loja. Queremos transformar nosso site de blog simples em um aplicativo de comércio eletrônico e começar a vender itens como camisetas, canecas e adesivos.

Todos os componentes que um aplicativo de comércio eletrônico contém podem usar a mesma técnica de pré-renderização. Podemos usar a função getStaticProps para buscar nossos dados em tempo de construção.

Agora, o que podemos usar em nossa sessão de checkout? Todo aplicativo de comércio eletrônico deve ter uma sessão de checkout onde o usuário finalizará sua compra. Nesse caso, os dados podem ser buscados em nosso banco de dados no momento da construção, mas podem ser diferentes para cada usuário.

Podemos usar a busca do lado do cliente na parte superior do SSG para renderizar nossa página. Podemos criar nosso componente simples sem usar nenhuma função para buscar dados em tempo de construção e, dentro de nosso componente, podemos usar uma biblioteca de busca de dados, como SWR para buscar nossos dados no lado do cliente:

 importar useSWR de"swr";
função padrão de exportação CheckoutSession () { const {data, error}=useSWR ("/api/checkout", buscador) if (erro) return 
 Algo deu errado... 
 if (! data) return 
 Carregando... 
 return 
 Cart: {data.items.length} 
}

Usar a renderização do lado do servidor com getServerSideProps pode fazer o trabalho na maioria das vezes. O problema é que você pode perder alguns recursos e vantagens que o SSG traz para os aplicativos Next.js. A página será pré-renderizada em cada solicitação usando os dados retornados. Outra desvantagem é que você não pode usar um [fetch ()] ( https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch ) método para chamar uma API dentro do getServerSideProps .

O fato de a página ser pré-renderizada no momento da criação aumenta o desempenho e faz com que a página pareça mais rápida.

O HTML também pode ser obtido por um servidor CDN, o que também pode melhorar o desempenho.

Outro recurso interessante do SSG é que não há necessidade de fazer uma solicitação ao banco de dados. A página é pré-renderizada no momento da construção, então mesmo que seu banco de dados caia, você ainda poderá renderizar sua página.

Conclusão

Next.js se tornou uma das estruturas React mais importantes na comunidade da web. Trouxe para os desenvolvedores muitos recursos para ajudar a construir sites mais complexos e ricos.

Usar uma estrutura como Next.js nos permite usar diferentes técnicas de pré-renderização em nossos aplicativos. Podemos usar a geração de sites estáticos para algo mais simples e não dinâmico. Podemos usar a renderização do lado do servidor para conteúdo dinâmico e páginas mais complexas. Com essas ferramentas, construir aplicativos da web sofisticados se tornou mais fácil e divertido.

A postagem SSG vs SSR em Next.js apareceu primeiro no LogRocket Blog .