Next.js Data Fetching Busca de Dados no Next.js
Última atualização: 2026-11-03
Next.js Data Fetching Busca de Dados no Next.js
Em um server component do Next.js você pode aguardar o fetch diretamente, e o next.revalidate controla a estratégia de cache: SSG, ISR e SSR são expressos através da mesma API. O cache é o comportamento padrão, então entender as estratégias é o que permite equilibrar velocidade e atualização dos dados sem abrir mão de nenhum dos dois.
| Grupo | Ecossistema |
|---|---|
| Tipo | Padrão |
| Desde | Next.js 13.4+ (App Router estável); o fetch não é mais cacheado por padrão desde 15 |
ℹ️ Informação O editor transpila JSX para JavaScript e renderiza a UI real na sandbox; os componentes são montados automaticamente — sem render manual.
📝 Sintaxe
// Fetch directly inside a server component (no useEffect needed)
const res = await fetch('https://api.example.com/posts', {
next: { revalidate: 60 } // ISR: cached for 60 seconds
})
const posts = await res.json()
// Other strategies:
// next: { revalidate: 0 } → SSR: fetched fresh on every request
// cache: 'no-store' → no caching at all (same as SSR)
// no options at all → SSG: fetched once at build time
// next: { tags: ['posts'] } → tagged, so revalidateTag can invalidate it precisely⚙️ Parâmetros
| next.revalidate | Quantos segundos o cache vive: 0 busca novamente a cada requisição (SSR), deixar sem definir busca uma vez em tempo de build (SSG), e N regenera o cache em segundo plano a cada N segundos (ISR). |
|---|---|
| cache: 'no-store' | Desabilita o cache por completo, o que equivale a renderização dinâmica e convém a dados fortemente em tempo real. |
Retorna：Sem valor de retorno — os dados são buscados no servidor; as estratégias estão descritas na sintaxe e no exemplo.
▶ Exemplo
O exemplo roda direto: renderiza automaticamente ao expandir e edições valem na hora.
Saída：
Simulação: clique nos botões SSG / ISR / SSR para trocar de estratégia; o painel abaixo mostra a opção revalidate correspondente, a atualização dos dados (snapshot em tempo de build, no máximo 60 segundos atrás, ou ao vivo) e uma breve nota sobre o caso de uso, o que facilita comparar a escolha entre velocidade e atualização.💡 Pontos-chave
⚠️ Aviso Desde o Next.js 15 o fetch não é mais cacheado por padrão: para obter SSG ou ISR você precisa escrever next.revalidate explicitamente, então o comportamento difere da versão 14.
💡 Dica Marque suas requisições com fetch(url, { next: { tags: ['posts'] } }) e chame revalidateTag('posts') após as mudanças de dados para invalidar exatamente as entradas de cache certas, em vez de regenerar o site inteiro.
ℹ️ Informação Client components ainda buscam dados com useEffect ou TanStack Query; a lógica de busca no servidor não deve ficar em um arquivo marcado com 'use client'.
🏷️ Mais Ecossistema
💡 Casos Relacionados
Mais casos em breve.
📚 Tutoriais Relacionados
❓ Perguntas Frequentes
P Como busco dados em um server component?
R Basta aguardar fetch(...) dentro de um componente async — sem useEffect e sem gerenciamento de estado. A requisição acontece no servidor em tempo de build ou de requisição, então nada extra é enviado ao navegador.
P Como escolho entre SSG, ISR e SSR?
R Use SSG para conteúdo que raramente muda (documentação, posts de blog), ISR para dados que precisam de atualizações regulares (páginas de produtos, listagens) e SSR para dados totalmente personalizados ou estritamente em tempo real. Páginas diferentes de um mesmo site podem misturá-los livremente.
P Um client component pode buscar dessa forma?
R Não. A opção next.revalidate só surte efeito no servidor; em um client component use useEffect, SWR ou TanStack Query e trate os estados de carregamento e erro você mesmo.
