Pontos-chave
- A recuperação de dados no Next.js dentro dos componentes de servidor oferece um excelente desempenho, mas, a partir da versão 15, tens de ativar manualmente o cache.
- Para atualizações contínuas em segundo plano ou interações dinâmicas do lado do cliente, usar ferramentas como o SWR simplifica o teu código e evita uma gestão de estado complicada.
- O Next.js elimina automaticamente as solicitações de rede duplicadas e gere os estados de carregamento da interface do utilizador através de ficheiros de encaminhamento integrados, para manter o teu código organizado.
A recuperação de dados em aplicações React normais é bastante simples. O que quero dizer com isto é: fazes uma chamada à API dentro de um componente e renderizas o resultado.
Mas o Next.js lida com as coisas de forma diferente.
O que isto significa é que, em vez de esperares que a página carregue no navegador para obter os teus dados, agora fazes chamadas à API diretamente no servidor antes de a página ser enviada para o utilizador.
Neste guia, vou explicar como funciona a recuperação de dados no Next.js. Vou falar sobre a diferença entre a recuperação do lado do servidor e do lado do cliente, os diferentes métodos que podes usar, como a API nativa do fetch, o SWR e o Axios, e abordar as melhores práticas.
Ah, e também vou falar de um mini-projeto para que possas ver como funciona a recuperação de dados na prática.
O que é a recuperação de dados no Next.js?
A recuperação de dados é bastante intuitiva. É o processo de obter dados de uma fonte externa, por exemplo, uma base de dados ou uma API REST, e apresentá-los no teu próprio site.
Se já usaste o Next.js há alguns anos, talvez te lembres de ter usado funções como getServerSideProps ou getStaticProps para obter os teus dados. O Next.js já não as usa.
Agora usa o App Router e tudo está construído em torno dos React Server Components. Por isso… em vez de teres de aprender um monte de funções específicas do Next para obter os teus dados, podes simplesmente usar JavaScript assíncrono normal.
O que quero dizer é que podes chamar a API normal de recuperação de dados da Web dentro dos teus componentes de servidor e deixar que o Next.js trate do trabalho pesado.
Recuperação do lado do servidor vs. recuperação do lado do cliente: qual deves usar?
Quando tiveres de escolher entre a recuperação do lado do servidor e do lado do cliente, o meu conselho é que começes sempre pelo servidor.
Digo isto porque, por predefinição, todos os componentes no Next.js são, de qualquer forma, componentes de servidor. E, sinceramente, é esta a abordagem que deves seguir na maioria das vezes.
Porquê?
Para começar, é melhor para o SEO. Os motores de busca conseguem ler o HTML totalmente renderizado. Além disso, não te esqueças da segurança. As tuas palavras-passe da base de dados e as chaves API ficam ocultas no servidor e nunca aparecem no navegador do utilizador.
E, por último, as páginas carregam mais depressa, já que estás a enviar muito menos JavaScript para o cliente.
Mas e os componentes do cliente?
Bem, às vezes precisas mesmo deles. Por exemplo, quando estás a criar uma página altamente interativa ou quando precisas de usar ferramentas específicas do navegador, como o armazenamento local, aí tens de usar o «client». E usá-lo é tão simples quanto colocar «use client» no início do ficheiro do teu componente.
Para facilitar ainda mais a compreensão, normalmente usas a recuperação de dados do lado do cliente para coisas como um chat em tempo real ou um painel de controlo em que os dados têm de ser atualizados a cada segundo.
Alojamento PHP rápido e escalável para APIs REST personalizadas
Garante que a tua aplicação Next.js recupere dados sem demora. A Cloudways oferece recursos dedicados e cache avançado para APIs de backend altamente responsivas.
3 formas de obter dados no Next.js
Vamos agora ver algumas formas de realmente importares dados para a tua aplicação. Dependendo do que estiveres a desenvolver, provavelmente vais usar uma das três abordagens que vou abordar a seguir.
Método 1: A API nativa fetch (do lado do servidor)
Se estiveres a usar o App Router, a abordagem mais sensata é usar a API fetch nativa dentro de um componente de servidor assíncrono.
O que é fixe nisto é que o Next.js basicamente pegou na API padrão de fetch da web e adicionou-lhe controlos de cache.
Uma coisa a ter em conta aqui é que, a partir do Next.js 15, os pedidos fetch já não são armazenados em cache por predefinição, ao contrário das versões anteriores. Agora, o Next.js vai buscar dados atualizados em cada pedido.
Mas ainda assim podes usar o cache. Por exemplo, se tiveres dados estáticos e quiseres armazenar uma solicitação em cache para evitar que seja executada sempre que a página for carregada, basta passares uma opção de cache forçado assim:
const res = await fetch('https://api.example.com/data', {
cache: 'force-cache'
});
E se quiseres que esses dados sejam atualizados automaticamente com frequência, por exemplo, a cada poucos minutos, podes facilmente substituir o «force-cache» por um temporizador de revalidação. É super flexível e já vem integrado.
Método 2: Obtenção de dados do lado do cliente com o SWR
Apesar de a recuperação de dados do servidor já ser a norma, às vezes ainda vais precisar de recuperar dados do lado do cliente. Já expliquei isto anteriormente. Um bom exemplo de recuperação do lado do cliente é um painel em tempo real que precisa de ser atualizado constantemente sem recarregar a página.
Em vez de escrever um hook useEffect um pouco complicado para gerir a recuperação de dados do lado do cliente, a abordagem mais fácil é usar o SWR (Stale-While-Revalidate). É uma biblioteca leve criada pela Vercel, que consegue gerir o cache e os estados de carregamento automaticamente.
Aqui está um exemplo rápido de como o usarias dentro de um Componente Cliente:
'use client';
import useSWR from 'swr';
const fetcher = (url: string) => fetch(url).then(res => res.json());
export default function Dashboard() {
const { data, error, isLoading } = useSWR('https://api.example.com/stats', fetcher);
if (error) return
; if (isLoading) return
; return
; }
Repara que adicionei «use client» mesmo no início do meu ficheiro de componente. Fiz isso porque o SWR depende exclusivamente dos hooks do React, e os hooks só funcionam no lado do cliente.
Método 3: Obter dados com o Axios
Se quiseres usar uma alternativa à API fetch padrão, o Axios é outra opção. Muitos programadores simplesmente preferem-no porque já se sentem à vontade a usá-lo nos seus projetos React mais antigos.
Na minha opinião, a maior vantagem do Axios é que ele analisa automaticamente os dados JSON por ti. Além disso, lida com as respostas de erro de uma forma mais simples do que a API fetch nativa.
Além disso, o Axios pode ser usado tanto no lado do servidor como no lado do cliente, o que o torna versátil. Eis como o usarias dentro de um Componente de Servidor assíncrono:
import axios from 'axios';
interface Post {
id: number;
title: string;
}
export default async function PostsPage() {
// Axios automatically throws an error if the request fails
const res = await axios.get<Post[]>('https://api.example.com/posts');
const posts = res.data;
return (
{posts.map(post => (
{post.title}
))}
); }
Nota rápida: como o Axios é um pacote de terceiros, lembra-te de que vais ter de executar o comando «npm install axios» antes de o poderes usar no teu código.
Melhores práticas para a recolha de dados no Next.js
Antes de falar do miniprojeto, deixa-me explicar-te algumas boas práticas. Seguir estas dicas vai poupar-te muitas dores de cabeça e fazer com que a tua aplicação funcione significativamente mais rápido e sem problemas.
1. Recolhe os dados exatamente onde precisares
Nas aplicações React mais antigas, costumavas ir buscar os dados no nível superior e passá-los para baixo através das props. Já não precisas de fazer isso. Em vez disso, basta ires buscar os dados diretamente dentro do componente que precisa deles.
O Next.js elimina automaticamente as duplicatas das tuas solicitações. Isto significa que, se chamares a mesma API em três sítios diferentes, na verdade só é feita uma única solicitação de rede.
2. Faz as consultas em paralelo para evitar o efeito cascata
Se tiveres duas chamadas à API que não dependem uma da outra, não precisas de esperar que a primeira termine para iniciares a segunda. Em vez de escreveres chamadas ` await ` uma a seguir à outra, podes simplesmente usar o `Promise.all` para lançares ambas as chamadas exatamente ao mesmo tempo. Isto acelera significativamente o tempo de carregamento da tua página.
3. Aproveita os ficheiros loading.tsx e error.tsx
O Next.js tem uma forma muito simples de lidar com os estados de carregamento e de erro. Assim, em vez de os gerires manualmente, podes adicionar facilmente um ficheiro loading.tsx ou error.tsx à tua pasta de rotas.
O Next.js consegue detetar automaticamente estes ficheiros e mostrar um ecrã de carregamento enquanto recupera os dados, além de tratar com segurança quaisquer erros caso a API falhe.
Vou mostrar-te como usar estes ficheiros no mini-projeto de que vou falar a seguir.
Mini-projeto: Como obter dados de uma API REST no Next.js
Para vos mostrar como funciona a nova forma de obter dados em JavaScript quando a usas na prática, vou criar um mini-projeto como exemplo. Vou mantê-lo simples e criar uma página de«Publicações mais recentes» que vai buscar as publicações mais recentes de uma API REST pública.
Para este projeto, vou usar um App Router para ir buscar os dados. Também vou adicionar um ecrã de carregamento temporário que vai aparecer enquanto os dados estão a ser recuperados.
No meu caso, como tenho restrições de TI no meu portátil de trabalho, vou usar um binário independente do Node.js.
E para executar tudo localmente, vou usar:
- Linha de comandos (CMD)
- VS Code
- A minha pasta Node local
Passo 1: Configurar o ambiente do Next.js
Primeiro, vou criar a estrutura básica da minha aplicação Next.js. Como tenho a versão binária autónoma, vou indicar ao Prompt de Comandos onde fica a pasta do Node no meu portátil.
Para indicar a este CMD onde estão as minhas ferramentas do Node, vou executar este comando:
set PATH=%PATH%;C:\Users\abdulrehman\Downloads\node-v24.15.0-win-x64\node-v24.15.0-win-x64
Este comando vai indicar ao CMD o caminho onde descompactei a minha pasta do Node.
Para verificar rapidamente se está tudo a funcionar, vou executar estes dois comandos, um a seguir ao outro:
node -v npm -v
Como consigo ver os números de versão tanto do Node como do npm, até agora está tudo bem.
Agora já estou pronto para executar os comandos padrão do Next.js. Com isso, vou criar o meu projeto executando:
npx create-next-app@latest my-blog-project
O Prompt de Comando vai agora perguntar-me algumas preferências de configuração. Para simplificar, vou escolher «Sim» para o TypeScript, o ESLint, o Tailwind CSS e o App Router.
Assim que o processo de instalação terminar, vai ser criada uma nova pasta chamada «my-blog-project» com todos os ficheiros necessários.
Passo 2: Criar a rota e a função de recuperação
Vou agora abrir a pasta «my-blog-project», que acabei de criar, no VS Code.
Agora, vou precisar de uma página para mostrar as publicações que vou recuperar. Para criar a página, que pode ser acedida localmente em: localhost:3000/posts, vou à pasta da minha aplicação e vou criar uma nova pasta chamada «posts».
Depois, dentro da pasta, vou criar um ficheiro chamado page.tsx. É este o ficheiro que contém a interface do utilizador.
No ficheiro page.tsx, vou escrever uma função para tratar de todas as chamadas à API REST. Vou usar a API Web Fetch para obter dados desta fonte para este tutorial: https://jsonplaceholder.typicode.com/posts.
A fonte de que falei é um serviço gratuito e acessível ao público chamado JSONPlaceholder. Como o nome sugere, fornece dados fictícios que os programadores podem usar para testar as suas aplicações sem terem de recorrer a uma base de dados real.
Aqui está o código que vou adicionar ao meu ficheiro page.tsx:
// Define the shape of the data I expect from the API
type Post = {
id: number;
title: string;
body: string;
};
// My asynchronous fetch function
async function getPosts() {
const response = await fetch('https://jsonplaceholder.typicode.com/posts', {
// Re-fetch the data every hour (3600 seconds)
next: { revalidate: 3600 }
});
if (!response.ok) {
throw new Error('Failed to fetch posts');
}
return response.json();
}
Agora que a minha lógica de recuperação já está no ficheiro, vou criar a interface de utilizador que vai chamar a minha função de recuperação para mostrar os dados obtidos.
Passo 3: Criar o componente do servidor
Agora vou criar a lógica para mostrar as publicações que vão ser recuperadas, na página que criei há pouco.
Para isso, vou usar a função getPosts() para ir buscar os dados. Depois, vou usar a função map() para percorrer as publicações. E, por fim, vou apresentar cada publicação num cartão com o estilo do Tailwind CSS.
Este é o código da função getPosts() que vou adicionar ao meu ficheiro page.tsx, logo a seguir à função fetch:
export default async function PostsPage() {
// Call the fetch function and wait for the data
const posts: Post[] = await getPosts();
return (
Latest Posts
{/* Loop through the first 6 posts for display */} {posts.slice(0, 6).map((post) => (
{post.title}
{post.body}
))}
); }
Últimas publicações
{/* Percorre as primeiras 6 publicações para exibição */} {posts.slice(0, 6).map((post) => (
{post.title}
{post.body}
))}
Nesta altura, a minha página já está pronta e deve mostrar as publicações corretamente. No entanto, se a API demorar mais tempo do que o habitual a responder, os meus utilizadores não vão ver nada enquanto os dados estão a ser carregados. Para melhorar a experiência do utilizador, vou adicionar um indicador de carregamento a seguir.
Passo 4: Adicionar um estado de carregamento automático
O Next.js facilita a gestão dos estados de carregamento através de uma convenção especial de ficheiros, por isso não preciso de lidar com estados complexos do React.
Para adicionar o estado de carregamento, dentro da minha pasta app/posts, vou criar um novo ficheiro chamado loading.tsx.
O que isto vai fazer é permitir que o Next.js detete o meu ficheiro loading.tsx e mostre o seu conteúdo enquanto o componente PostsPage espera que a chamada à API REST termine.
Vou adicionar este código ao ficheiro loading.tsx para mostrar uma mensagem simples que diga «A carregar publicações…» enquanto os dados são recolhidos:
export default function Loading() {
return (
Latest Posts
); }
Últimas publicações
); }
Nesta fase, já está tudo pronto. Tenho uma função para ir buscar publicações, um componente para as apresentar e uma mensagem temporária de carregamento para melhorar a experiência do utilizador.
Agora, a única coisa que preciso de fazer é iniciar o servidor de desenvolvimento local para testar o que criei.
Passo 5: Executar e testar a aplicação
Pronto… está na hora de testar. Vou voltar ao CMD e ir para a pasta do meu projeto. Para isso, vou escrever «cd my-blog-project».
Nota rápida: Como já tinha configurado a minha variável PATH no Passo 1, a janela do prompt de comandos já sabe onde estão as minhas ferramentas do Node.
Então… agora já posso simplesmente iniciar o servidor de desenvolvimento executando:
npm run dev
Assim que o servidor arrancar, vou abrir este URL no meu navegador: http://localhost:3000/posts.
E se tudo tiver corrido bem, quando a página carregar, devias ver uma grelha com as seis publicações mais recentes, obtidas diretamente da API REST.
E, como podes ver na captura de ecrã abaixo, funciona mesmo.
Para resumir rapidamente como tudo funciona: o Next.js foi buscar os dados através da API REST, inseriu-os nos cartões criados com o Tailwind e enviou o HTML já pronto para o teu navegador.
Passo 6: Enviar para o GitHub e implementar no Cloudways Velocity
Como está tudo a funcionar bem na minha configuração local, vou colocar este projeto online. Vou enviar o código para o GitHub e, depois, implementá-lo na hospedagem gerida do Node.js da Cloudways (Velocity).
Enviar o código para o GitHub
Primeiro, vou ao GitHub e vou criar um novo repositório. Depois, vou abrir a linha de comandos, parar o servidor de desenvolvimento e executar os comandos padrão do Git para enviar os ficheiros do meu projeto para o novo repositório.
Lançar a aplicação no Cloudways
A seguir, vou ao meu painel do Cloudways para criar uma nova aplicação Node.js. No menu da esquerda, vou clicar em «Velocity» e depois em «Começar».
Depois, vou escolher o plano básico e clicar em «Continuar».
Ligar o meu repositório do GitHub
Agora preciso de ligar o meu código. O Cloudways dá-te a opção de te ligares ao GitHub, ao GitLab ou ao Bitbucket. Como o meu código está no GitHub, vou ligar-me a esse.
Assim que o meu Git estiver ligado, vou escolher o meu repositório no menu suspenso e clicar em «Continuar».
O Cloudways define automaticamente as configurações da minha aplicação. Configura o framework para Next.js SSR, o ramo para «main» e usa o Node 24 (LTS). Não preciso de configurar nada disto manualmente.
Implementar a aplicação
Agora vou clicar em «Deploy Now» e o Cloudways vai começar a buscar o código do meu GitHub, instalar todas as dependências do npm, executar o comando de compilação e iniciar o servidor.
Verificar a página em tempo real
Assim que a implementação terminar, vou ir buscar o URL temporário na página «Visão geral» da aplicação, no painel de controlo.
Agora, quando abro esse URL seguido de /posts numa nova aba do navegador, devia ver exatamente a mesma página «Últimas publicações» a obter dados da API REST, tal como acontecia localmente.
A recuperação de dados já está a funcionar na perfeição num servidor em produção.
Conclusão
A recuperação de dados no Next.js pode parecer um pouco diferente se estiveres habituado a trabalhar com aplicações React tradicionais. Dito isto, é muito fácil de usar assim que apanhares o jeito.
Na maioria dos casos, usar a API fetch nativa dentro dos Componentes de Servidor vai dar-te o melhor desempenho. Mas, em alguns casos, vais precisar de usar o SWR para atualizações do lado do cliente, ou o Axios, se for isso que estás habituado a usar.
Assim que a tua aplicação Next.js estiver compilada e a recuperar dados sem problemas, a última coisa que vais querer é que um servidor lento estrague todo esse desempenho. Para evitar isso, quando estiveres pronto para colocar a tua aplicação em produção, escolhe o Cloudways Velocity.
Os nossos servidores dedicados na nuvem oferecem recursos de computação de primeira linha e camadas de cache otimizadas, necessárias para executar os componentes de servidor do Next.js e as rotas da API sem problemas.
O projeto completo está disponível no meu GitHub. Sente-te à vontade para cloná-lo e usar o código. Se tiveres alguma dúvida sobre os métodos de obtenção de dados ou o processo de implementação, é só me avisares nos comentários.
P1. Ainda posso armazenar em cache os pedidos de recuperação no Next.js 15?
A. Sim, mas já não é a configuração por predefinição. Se quiseres implementar o cache, tens de adicionar manualmente a opção `cache: ‘force-cache’` à tua chamada `fetch`, se quiseres que dados específicos fiquem armazenados.
P2. Posso usar a API fetch nativa dentro de um componente cliente?
A. Podes, mas é melhor usares uma ferramenta como o SWR do lado do cliente. Digo isto porque o SWR gere automaticamente os estados de carregamento e as atualizações em segundo plano, poupando-te de teres de escrever hooks useEffect.
P3. É mau usar o Axios em vez do fetch no Next.js?
A. De todo. Na verdade, muitos programadores ainda preferem o Axios porque analisa automaticamente o JSON e lida com os erros de forma clara. Além disso, funciona na perfeição tanto no lado do servidor como no lado do cliente.
P4. Por que é que o Next.js deixou de armazenar em cache o `fetch` por predefinição?
A. Mudaram isto no Next.js 15 porque muitos programadores estavam a ficar confusos com a exibição de dados desatualizados. Carregar dados atualizados em cada pedido é simplesmente muito mais previsível.
P5. Preciso mesmo do ficheiro loading.tsx se já tiver os meus próprios estados de carregamento?
A. Não, não é estritamente necessário, mas ajuda porque torna o teu código muito mais limpo. Permite que o Next.js trate da renderização da interface de utilizador automaticamente enquanto os teus componentes de servidor recuperam os dados. Isto significa que, no final das contas, escreves muito menos código.
Abdul Rehman
O Abdul é um profissional de marketing experiente em tecnologia, movido a café e criativo, que adora manter-se a par das últimas actualizações de software e gadgets tecnológicos. É também um escritor técnico competente que consegue explicar conceitos complexos de forma simples para um público alargado. Abdul gosta de partilhar os seus conhecimentos sobre a indústria da nuvem através de manuais de utilizador, documentação e publicações em blogues.
