Comparação de 5 alternativas ao node-fetch: Native Fetch, Axios, Got, Ky e SuperAgent

Não existe um vencedor universal entre as alternativas ao `node-fetch`. Comece por identificar a funcionalidade de que a sua aplicação realmente necessita e, em seguida, verifique a versão principal instalada e a versão de base do Node.js.

Estas opções dividem-se em três categorias: uma API de tempo de execução, um wrapper do Fetch e clientes HTTP completos. Compare dentro da categoria correta, em vez de tratar cada lacuna de funcionalidades como um defeito.

Encare a decisão como «manter», «remover» ou «substituir». Mantenha o node-fetch quando o seu comportamento atual estiver coberto por testes, as suas restrições de tempo de execução o justifiquem e a migração não traga qualquer benefício operacional concreto. Remova-o quando as versões de Node.js que suporta já exponham o Fetch global e o seu código necessite apenas de pedidos em conformidade com os padrões. Substitua-o quando novas tentativas, hooks, timeouts faseados, transformações centralizadas ou auxiliares de upload se estiverem a tornar-se infraestrutura mantida pela aplicação.

Um guia prático para efetuar pedidos HTTP com o `node-fetch` pode continuar a ser útil quando estiver a manter uma integração existente. O pacote não é automaticamente a escolha errada simplesmente porque os ambientes de execução mais recentes incluem o `Fetch`. A questão relevante é se outra opção reduz o risco ou o código sem alterar silenciosamente a semântica.

O Fetch nativo reduz a superfície de dependências e alinha o código do servidor com o modelo padronizado de Request, Response, Headers e Body. A documentação global oficial do Fetch do Node.js regista o seu histórico de versões e estabilidade, que deve verificar em relação ao ambiente de execução exato implementado em produção.

Não confie num suposto tempo limite da plataforma. Defina um prazo explícito com o AbortController ou utilize AbortSignal.timeout() apenas após confirmar que a API existe em todas as versões suportadas do Node.js.

A documentação do node-fetch capturada descreve a v3 como exclusiva para ESM e a v2 como compatível com CommonJS. Também refere declarações TypeScript incluídas para a v3 e um limite mínimo mais antigo do Node.js, mas esses detalhes e orientações de manutenção estão sujeitos a alterações. Confirme os metadados do pacote antes de padronizar qualquer uma das versões.

Faça o mesmo com o Axios, o Got, o Ky e o SuperAgent. Verifique engines, type, exportse types com npm view <package> engines type exports types, e, em seguida, teste a forma de importação efetiva na CI. As versões principais atuais podem diferir no suporte a ESM, na interoperabilidade com CommonJS e nos requisitos de tempo de execução.

Use isto como uma lista de pré-seleção. B significa integrado, A significa complemento ou adaptador e M significa código de aplicação manual. Um asterisco indica uma funcionalidade sensível ao tempo que requer verificação específica para cada versão.

A lista de funcionalidades mais extensa raramente é o melhor critério. Defina o contrato de solicitação: codificação do corpo, erros de estado, prazos, novas tentativas e o tipo de fluxo transmitido a jusante. A escolha entre alternativas de node-fetch só é segura quando esses comportamentos se mantêm intencionais.

Este guia exclui classificações de velocidade, contagens de downloads, estrelas, alegações sobre o tamanho do pacote e tabelas de classificação de manutenção. Sem medições recentes, datas e um método definido, esses números criam uma falsa precisão, em vez de uma decisão de engenharia sólida.

Os clientes do tipo «fetch» requerem normalmente JSON.stringify(), cabeçalhos de conteúdo, análise de respostas e response.ok verificações. O Axios transforma cargas úteis de objetos, expõe o conteúdo analisado em response.datae rejeita respostas que não sejam 2xx por predefinição, a menos que validateStatus essa regra seja alterada. Essa diferença pode fazer com que o código seja transferido de um ramo normal para catch.

Defina prazos explicitamente, independentemente do cliente. Distinga um prazo total da solicitação das fases de ligação, TLS, primeiro byte e socket. As tentativas de repetição também necessitam de uma política escrita. Repetir uma solicitação GET após uma falha transitória é diferente de repetir uma solicitação POST que já possa ter sido confirmada. Trate o suporte à repetição automática como um mecanismo de políticas, não como uma opção de seleção.

Para serviços Node.js e scraping, os detalhes de transporte determinam frequentemente o cliente. O suporte a proxies pode provir de uma opção do cliente, de um agente HTTP, de um despachante Fetch ou de um adaptador. A persistência de cookies requer normalmente um jar ou lógica de aplicação, uma vez que os clientes do lado do servidor não herdam o armazenamento de cookies do navegador.

Verifique se os corpos das respostas são fluxos do Node.js Readable ou objetos WHATWG ReadableStream antes de alterar os pipelines de download. Verifique o comportamento do FormData multiparte, os limites de tamanho de ficheiro, o tratamento de redirecionamentos, a descompressão e a contrapressão. O suporte a HTTP/2 pode pertencer ao cliente, a uma extensão ou ao ambiente de execução subjacente.

Um guia prático para a configuração de proxy no node-fetch e um guia mais abrangente sobre web scraping com JavaScript e Node.js são recursos essenciais quando estas questões de transporte dominam a migração.

Para ambientes de execução suportados, o Fetch nativo deve ser a primeira base de referência em relação à qual outras alternativas ao node-fetch são avaliadas. Preserva a interface familiar baseada em promessas sem um pacote de cliente externo, mas também mantém a explicitação deliberada do Fetch: serializa-se o JSON, analisa-se o corpo da resposta e decide-se o que um erro HTTP significa.

const controller = new AbortController();
const timer = setTimeout(() => controller.abort(), 5_000);

try {
  const response = await fetch('https://api.example.com/items', {
    signal: controller.signal
  });

  if (!response.ok) {
    throw new Error(`HTTP ${response.status}`);
  }

  const items = await response.json();
  console.log(items);
} finally {
  clearTimeout(timer);
}

Este exemplo define o seu próprio prazo, em vez de assumir um valor por defeito não documentado. Falhas de rede e cancelamentos rejeitam a promessa, enquanto um erro 404 ou 500 continua a produzir uma resposta que o seu código deve inspecionar. Esse comportamento segue o padrão Fetch mais abrangente.

A principal armadilha da migração são os fluxos. O node-fetch expõe corpos legíveis pelo Node.js, enquanto o Fetch nativo segue a semântica dos fluxos da Web. Se o código existente canalizar diretamente para stream.pipeline, adapte ou converta o corpo e realize testes de regressão para verificar a contrapressão, o cancelamento e a propagação de erros.

O Axios é uma forte alternativa ao `node fetch` quando a conveniência deve ser centralizada entre o código do navegador e do servidor. Passar um objeto simples como dados de pedido aciona a serialização JSON e o tratamento adequado do conteúdo, e os dados da resposta analisados ficam disponíveis através de response.data. Por predefinição, os códigos de estado que não sejam 2xx transformam-se em erros com detalhes do servidor em error.response.

As instâncias reutilizáveis permitem-lhe padronizar URLs de base, cabeçalhos, prazos e validateStatus. Os interceptores são middleware integrado para autenticação, rastreamento, registo, fluxos de atualização e transformação de respostas. Podem substituir código de wrapper repetitivo, mas também podem ocultar comportamentos; por isso, certifique-se de que a ordem dos interceptores e os percursos de falha são testados.

As tentativas de repetição não fazem parte do núcleo do Axios nas evidências capturadas. Adicione-as através de uma extensão ou política de aplicação e verifique os métodos elegíveis. O comportamento do proxy pode depender do protocolo, de variáveis de ambiente, de adaptadores ou de agentes personalizados; por isso, teste o caminho de implementação exato, em vez de assumir que uma única opção de proxy abrange tudo.

Um guia dedicado à configuração do proxy do Axios e um manual de cabeçalhos do Axios são recursos internos úteis para acompanhamento. Confirme também o nível mínimo de Node.js do pacote atual, as exportações de módulos, a API de cancelamento, o comportamento do fluxo e qualquer adaptador HTTP/2 antes de avançar.

O Got é a opção mais focada no Node.js neste conjunto de alternativas ao node-fetch. O seu valor reside no controlo: fases de timeout separadas podem abranger a pesquisa de DNS, a ligação, a negociação TLS, o envio do pedido, o primeiro byte de resposta, a inatividade do socket ou todo o ciclo de vida. Isso torna a telemetria de falhas mais útil do que um único timeout genérico.

O Got também disponibiliza hooks e APIs de streaming adequadas para integrações entre serviços. A documentação disponível descreve tentativas automáticas com backoff, compatibilidade com Retry-Aftere suporte nativo a HTTP/2, mas os valores predefinidos, os métodos elegíveis e o comportamento de transporte atual devem ser verificados para a versão principal instalada. Nunca permita que uma política de repetição predefinida repita uma solicitação que altere o estado sem uma estratégia de idempotência.

Para scraping ou gateways de API de saída, verifique a configuração do agente, o encaminhamento do proxy, a integração com o cookie-jar, a descompressão e os limites de fluxo. A superfície de opções mais rica do Got pode eliminar a necessidade de infraestrutura personalizada, mas aumenta a responsabilidade pela configuração. Prefira uma instância partilhada e revista em vez da proliferação de opções por chamada.

As versões atuais são geralmente documentadas como orientadas para ESM e exclusivas para o Node. Verifique engines, as exportações, os tipos incluídos e o estado de manutenção antes de escolher o Got para um serviço CommonJS ou um ambiente de execução mais antigo.

O Ky situa-se entre o Fetch nativo e um cliente HTTP completo do Node.js. Aceita entradas ao estilo do Fetch, ao mesmo tempo que adiciona atalhos de métodos, instâncias reutilizáveis, hooks e opções de pedido que reduzem o código repetitivo. Isso torna-o atraente quando se gosta da semântica do Fetch, mas se pretende um wrapper de aplicação mais pequeno.

A documentação atual deve ser consultada para conhecer o tempo de espera exato, os valores predefinidos de repetição de tentativas, os métodos elegíveis e o comportamento em caso de erro. A documentação disponível descreve as respostas que não sejam 2xx como erros e as repetições de tentativas como integradas, podendo ambos alterar o comportamento ao substituir o `node-fetch`. Preserve deliberadamente os seus ramos de estado existentes, em vez de deixar que um valor predefinido de conveniência decida por si.

O Ky delega comportamentos importantes de transporte à implementação subjacente do Fetch. A configuração do proxy ou do despachante, os cookies, os fluxos web, o FormData e o HTTP/2 dependem, portanto, em parte do tempo de execução. O progresso do download foi documentado em algumas versões, enquanto o suporte ao progresso do upload é mais limitado; por isso, verifique ambos antes de conceber telemetria em torno deles.

Escolha o Ky entre as alternativas ao node-fetch quando a compatibilidade com o Fetch for mais importante do que o controlo de transporte específico do Node.

O SuperAgent é uma alternativa pragmática ao `node-fetch` para equipas que preferem uma API fluente, como .get(), .set(), .send(), .field(), e .attach(). Os seus auxiliares para formulários e ficheiros tornam os fluxos de trabalho multiparte legíveis, enquanto a análise de respostas integrada e as APIs orientadas para o progresso podem simplificar o código de upload ou download.

A desvantagem é a distância semântica em relação ao `Fetch`. O tratamento de erros, a configuração de tempo limite, os redirecionamentos, o cancelamento e o acesso ao corpo da solicitação exigem um novo plano de testes, em vez de uma simples troca de importação. A documentação original contém afirmações contraditórias sobre hooks e o suporte ao `AbortController`. Trate os plugins como complementos e confirme se a versão que selecionou utiliza o seu próprio método de abortamento, aceita sinais ou requer um wrapper.

Da mesma forma, verifique o comportamento de repetição de tentativas e os métodos elegíveis antes de o ativar, e não presuma que o HTTP/2 é parte integrante sem documentação atualizada. No Node.js, analise o comportamento do agente, do proxy, da persistência de cookies e do fluxo para o seu fluxo de trabalho específico.

O SuperAgent é mais adequado quando as suas formas encadeáveis e APIs de ficheiros substituem código personalizado significativo, e não apenas porque a sintaxe parece concisa.

Uma migração segura começa por registar a semântica existente e, em seguida, alterar uma camada de cada vez. Se migrar para o Fetch nativo, a menor alteração que preserve o comportamento poderá ser a remoção da importação, mantendo a serialização JSON explícita, as verificações de estado e o cancelamento.

// Before
import fetch from 'node-fetch';
await sendJson(fetch);

// After
await sendJson(globalThis.fetch);

async function sendJson(fetchImpl) {
  const controller = new AbortController();
  const timer = setTimeout(() => controller.abort(), 5_000);

  try {
    const response = await fetchImpl('https://api.example.com/jobs', {
      method: 'POST',
      headers: {'content-type': 'application/json'},
      body: JSON.stringify({status: 'queued'}),
      signal: controller.signal
    });

    if (!response.ok) throw new Error(`HTTP ${response.status}`);
    return await response.json();
  } finally {
    clearTimeout(timer);
  }
}

Ao mudar para o Axios ou outro cliente que lança erros de estado, configure a sua política de estado ou reescreva intencionalmente o fluxo de controlo circundante. Não permita que um erro 404 passe acidentalmente de um resultado tratado para um caminho de repetição genérico.

• Confirme as importações ESM ou CommonJS e a versão mínima do Node.js implementada.
• Compare a serialização JSON, codificada por URL, Blob, File e FormData.
• Preserve o tratamento de códigos de erro que não sejam 2xx, os modos de redirecionamento e limites, bem como as suposições relativas a URLs absolutas.
• Verifique os tipos de erro de cancelamento e se os prazos abrangem todo o ciclo de vida.
• Lembre-se de que um corpo já consumido não pode ser lido duas vezes sem clonagem ou armazenamento em buffer.
• Converta explicitamente os fluxos do Node e os fluxos da Web e, em seguida, teste a contrapressão e as falhas parciais.
• Reconfigure proxies, agentes ou despachantes, armazenamentos de cookies, descompressão e limites de tamanho de resposta.
• Adicione testes de regressão para uploads, downloads de grande dimensão, novas tentativas, proteção contra POSTs duplicados e limpeza após abortos.

Utilize estes valores predefinidos de cenário para restringir as cinco alternativas do `node-fetch`:

• Serviço moderno com dependências mínimas: comece com o Fetch nativo.
• Aplicação CommonJS legada: mantenha o node-fetch v2 temporariamente ou escolha um cliente cujo caminho CommonJS atual e compatibilidade com o Node estejam verificados.
• Código partilhado entre navegador e servidor: avalie primeiro o Axios e, em seguida, o Ky, se a compatibilidade com o Fetch for mais importante do que os interceptores.
• Integração com o Node que envolve muitas tentativas: avalie o Got, com uma política de idempotência explícita.
• Formulários, anexos e progresso de upload: avalie o SuperAgent ou o Axios em função do fluxo de trabalho exato.
• Scraping baseado em proxy: escolha com base no controlo do agente ou do despachante, nos cookies, no tratamento de fluxos e nas necessidades de gestão de blocos, e não apenas na sintaxe do pedido.

Avalie primeiro o Fetch nativo em todas as versões do Node.js que efetivamente suporta. É a base de referência mais clara para decidir se outra dependência merece o seu lugar.

Escolha o Axios pelas conveniências entre diferentes ambientes de execução, o Got para controlos avançados do Node.js, o Ky pela ergonomia ao estilo do Fetch ou o SuperAgent para fluxos de trabalho encadeáveis de formulários e ficheiros. A melhor alternativa ao Fetch no Node.js é aquela cujas funcionalidades integradas e comprovadas substituam código personalizado significativo, preservando simultaneamente o seu contrato de pedidos.

• Avalie primeiro o Fetch nativo quando todas as versões de Node.js implementadas o suportarem e apenas necessitar de um comportamento HTTP explícito e em conformidade com os padrões.
• Escolha uma dependência pelas conveniências comprovadas que eliminam o código personalizado, e não pela lista de funcionalidades mais extensa.
• Preserve a codificação JSON, o tratamento de códigos de resposta que não sejam 2xx, os prazos, o cancelamento, o redirecionamento e a semântica de repetição de tentativas através de testes de regressão.
• Trate proxies, armazenamento de cookies, tipos de fluxo, uploads e HTTP/2 como questões de transporte que podem exigir agentes, adaptadores ou plug-ins.
• Verifique os metadados atuais do pacote e a documentação oficial antes de confiar em formatos de módulos, limites mínimos do Node.js ou valores por defeito.

Sim, desde que continue a ser compatível com o seu ambiente de execução suportado, política de segurança e expectativas de manutenção. Fixe a versão, reveja as orientações atuais do projeto e certifique-se de que o comportamento das solicitações está coberto por testes. Trate-o como uma decisão explícita de compatibilidade, não como um padrão permanente. Planeie uma saída caso uma futura atualização do Node.js, política de dependências ou pacote transitivo não suportado torne a utilização contínua dispendiosa.

A maioria dos clientes do lado do servidor necessita de um tratamento explícito de cookies ou de uma integração com um «cookie jar». O Fetch nativo e o node-fetch não se comportam como um armazenamento de cookies de um navegador. Outros clientes podem integrar-se com jars, agentes ou plugins, e um agente SuperAgent persistente pode ajudar em algumas versões. Verifique o comportamento relativo ao domínio, caminho, expiração, redirecionamento e pedidos simultâneos antes de confiar na persistência da sessão.

Não, não por predefinição. Uma solicitação POST com tempo de espera esgotado pode ter chegado ao servidor mesmo que o cliente nunca tenha recebido uma resposta. Repita a tentativa apenas quando a operação for concebida para repetição, normalmente com uma chave de idempotência, uma regra de deduplicação do lado do servidor ou um contrato seguro específico da aplicação. Limite também o número de tentativas e respeite os sinais de recuo do servidor, quando apropriado.

O corpo muda normalmente de um Node.js Readable para um WHATWG ReadableStream. O .pipe() ou stream.pipeline() pode, por isso, necessitar de conversão, como Readable.fromWeb() quando suportado, ou um pipeline de transmissão web. Teste a contrapressão, a propagação de abortos, ficheiros parciais, descompressão e limpeza, pois testes bem-sucedidos com buffers pequenos podem não revelar falhas de transmissão em produção.

A escolha certa entre as alternativas ao `node-fetch` depende do comportamento que pretende preservar e da infraestrutura que já não pretende manter. O Native Fetch é a base sensata para os ambientes de execução suportados, pois elimina uma dependência ao mesmo tempo que mantém a semântica familiar do Fetch. O Axios adiciona transformações e interceptores entre ambientes de execução, o Got enfatiza controlos detalhados do Node.js, o Ky envolve o Fetch com funcionalidades convenientes e o SuperAgent torna os fluxos de trabalho de formulários e ficheiros mais legíveis.

Antes de mudar, faça um inventário do contrato em torno de cada pedido. Verifique as importações, a serialização JSON, o tratamento de códigos de resposta que não sejam 2xx, os prazos, o cancelamento, a elegibilidade para repetição, os redirecionamentos, a persistência de cookies, o encaminhamento por proxy, os uploads e os tipos de fluxo. Em seguida, verifique os requisitos atuais do pacote e os valores predefinidos em relação à versão principal exata que pretende instalar.

Para cargas de trabalho de scraping, o cliente HTTP pode ser apenas uma camada do problema. Se bloqueios, CAPTCHAs e rotação de proxies estiverem a exigir mais esforço do que o tratamento das respostas, considere a API Scraper da WebScrapingAPI. Esta devolve HTML bruto enquanto trata dessa camada de pedidos. Mantenha a análise e a lógica de negócio na sua aplicação e utilize a opção de cliente que torne essas responsabilidades restantes mais claras.