Comparativa de 5 alternativas a node-fetch: Native Fetch, Axios, Got, Ky y SuperAgent

No hay un ganador universal entre las alternativas a node-fetch. Empieza por las capacidades que tu aplicación realmente necesita y, a continuación, comprueba la versión principal instalada y la versión base de Node.js.

Estas opciones se dividen en tres categorías: una API de tiempo de ejecución, un envoltorio de Fetch y clientes HTTP completos. Compáralas dentro de la categoría adecuada en lugar de considerar cada diferencia de funcionalidades como un defecto.

Considera la decisión en términos de «mantener», «eliminar» o «sustituir». Mantén node-fetch cuando su comportamiento actual esté cubierto por pruebas, tus limitaciones de tiempo de ejecución lo justifiquen y la migración no aporte ningún beneficio operativo concreto. Elimínalo cuando las versiones de Node.js que utilizas ya expongan Fetch global y tu código solo necesite peticiones conforme a los estándares. Sustitúyelo cuando los reintentos, los hooks, los tiempos de espera por fases, las transformaciones centralizadas o los ayudantes de subida se estén convirtiendo en infraestructura gestionada por la aplicación.

Una guía práctica para realizar peticiones HTTP con node-fetch puede seguir siendo útil cuando se mantiene una integración existente. El paquete no es automáticamente una mala elección simplemente porque los entornos de ejecución más recientes incluyan Fetch. La cuestión relevante es si otra opción reduce el riesgo o el código sin alterar silenciosamente la semántica.

Fetch nativo reduce la superficie de dependencias y alinea el código del servidor con el modelo estandarizado de Request, Response, Headers y Body. La documentación global oficial de Fetch para Node.js recoge su historial de versiones y estabilidad, que debes contrastar con el entorno de ejecución exacto desplegado en producción.

No confíes en un tiempo de espera de la plataforma que das por supuesto. Establece un plazo explícito con AbortController, o utiliza AbortSignal.timeout() solo después de confirmar que la API existe en todas las versiones compatibles de Node.js.

La documentación de node-fetch que hemos recopilado describe la v3 como exclusiva para ESM y la v2 como compatible con CommonJS. También indica que incluye declaraciones de TypeScript para la v3 y un mínimo de versión de Node.js más antiguo, pero esos detalles y las directrices de mantenimiento están sujetos a cambios. Confirma los metadatos del paquete antes de estandarizarte en cualquiera de las dos líneas.

Haz lo mismo con Axios, Got, Ky y SuperAgent. Revisa engines, type, exportsy types con npm view <package> engines type exports types, y después prueba la forma de importación real en la integración continua (CI). Las versiones principales actuales pueden diferir en cuanto a la compatibilidad con ESM, la interoperabilidad con CommonJS y los requisitos de tiempo de ejecución.

Utiliza esto como lista de preselección. B significa integrado, A complemento o adaptador, y M código de aplicación manual. Un asterisco indica una funcionalidad sujeta a cambios que requiere verificación específica para cada versión.

La lista de características más extensa rara vez es el mejor criterio. Define el contrato de solicitud: codificación del cuerpo, errores de estado, plazos, reintentos y el tipo de flujo que se transmite aguas abajo. La elección entre alternativas de node-fetch solo es segura cuando esos comportamientos siguen siendo intencionados.

Esta guía excluye clasificaciones de velocidad, recuentos de descargas, valoraciones con estrellas, afirmaciones sobre el tamaño de los paquetes y tablas de clasificación de mantenimiento. Sin mediciones recientes, fechas y un método bien definido, esas cifras crean una precisión engañosa en lugar de una decisión de ingeniería sólida.

Los clientes de tipo «fetch» suelen requerir JSON.stringify(), encabezados de contenido, análisis de respuestas y response.ok comprobaciones. Axios transforma las cargas útiles de los objetos, expone el contenido analizado en response.data, y rechaza por defecto las respuestas que no sean 2xx, a menos que validateStatus se modifique esa regla. Esa diferencia puede hacer que el código pase de una rama normal a catch.

Establece los plazos de forma explícita, independientemente del cliente. Distingue entre el plazo total de la solicitud y las fases de conexión, TLS, primer byte y socket. Los reintentos también requieren una política por escrito. Reintentar una solicitud GET tras un fallo transitorio es diferente a repetir una solicitud POST que quizá ya se haya completado. Trata la gestión de reintentos automáticos como un motor de políticas, no como una casilla de selección.

En el caso de los servicios Node.js y el scraping, los detalles de transporte suelen determinar el tipo de cliente. La compatibilidad con proxies puede provenir de una opción del cliente, un agente HTTP, un despachador Fetch o un adaptador. La persistencia de las cookies suele requerir un archivo JAR o lógica de aplicación, ya que los clientes del lado del servidor no heredan el almacén de cookies del navegador.

Comprueba si los cuerpos de respuesta son flujos de Node.js Readable o objetos WHATWG ReadableStream antes de modificar los flujos de descarga. Verifica el comportamiento de FormData multiparte, los límites de tamaño de archivo, la gestión de redireccionamientos, la descompresión y la contrapresión. La compatibilidad con HTTP/2 puede corresponder al cliente, a una extensión o al entorno de ejecución subyacente.

Una guía práctica para la configuración de proxies en node-fetch y una guía más amplia sobre el scraping web con JavaScript y Node.js son complementos ideales cuando estas cuestiones de transporte son el factor dominante en la migración.

En los entornos de ejecución compatibles, el Fetch nativo debería ser la primera referencia con la que evaluar otras alternativas a node-fetch. Conserva la conocida interfaz basada en promesas sin necesidad de un paquete de cliente externo, pero también mantiene la explicitud deliberada de Fetch: serializas JSON, analizas el cuerpo de la respuesta y decides qué significa un error HTTP.

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 ejemplo establece su propio plazo en lugar de asumir un valor predeterminado no documentado. Los fallos de red y las cancelaciones rechazan la promesa, mientras que un 404 o un 500 siguen generando una respuesta que tu código debe inspeccionar. Ese comportamiento sigue el estándar Fetch más amplio.

La principal trampa de la migración son los flujos. node-fetch expone cuerpos legibles para Node.js, mientras que Fetch nativo sigue la semántica de los flujos web. Si el código existente se canaliza directamente a stream.pipeline, adapta o convierte el cuerpo y realiza pruebas de regresión para la contrapresión, la cancelación y la propagación de errores.

Axios es una sólida alternativa a `node-fetch` cuando se busca centralizar la comodidad tanto en el código del navegador como en el del servidor. Al pasar un objeto simple como datos de solicitud, se activa la serialización JSON y el manejo adecuado del contenido, y los datos de la respuesta analizados están disponibles a través de response.data. Por defecto, los códigos de estado distintos de 2xx se convierten en errores con detalles del servidor en error.response.

Las instancias reutilizables te permiten estandarizar las URL base, los encabezados, los plazos y validateStatus. Los interceptores son middleware integrado para la autenticación, el rastreo, el registro, los flujos de actualización y la transformación de respuestas. Esto puede sustituir al código de envoltura repetitivo, pero también puede ocultar el comportamiento, por lo que es importante comprobar el orden de los interceptores y las rutas de fallo.

Los reintentos no forman parte del núcleo de Axios en la evidencia capturada. Añádelos mediante una extensión o una política de aplicación, y verifica los métodos elegibles. El comportamiento del proxy puede depender del protocolo, las variables de entorno, los adaptadores o los agentes personalizados, por lo que debes probar la ruta de implementación exacta en lugar de dar por sentado que una única opción de proxy lo cubre todo.

Una guía dedicada a la configuración del proxy de Axios y un manual de encabezados de Axios son recursos internos útiles para el seguimiento. Confirma también el nivel mínimo de Node.js del paquete actual, las exportaciones de módulos, la API de cancelación, el comportamiento de los flujos y cualquier adaptador HTTP/2 antes de confirmar el cambio.

Got es la opción más centrada en Node.js de este conjunto de alternativas a node-fetch. Su valor reside en el control: las fases de tiempo de espera independientes pueden abarcar la búsqueda de DNS, la conexión, la negociación TLS, el envío de la solicitud, el primer byte de respuesta, la inactividad del socket o todo el ciclo de vida. Esto hace que la telemetría de fallos sea más útil que un único tiempo de espera genérico.

Got también ofrece hooks y API de streaming adecuadas para integraciones de servicio a servicio. La documentación disponible describe reintentos automáticos con backoff, compatibilidad con Retry-Aftery compatibilidad nativa con HTTP/2, pero deben verificarse los valores predeterminados, los métodos elegibles y el comportamiento actual del transporte para la versión principal instalada. Nunca permitas que una política de reintentos predeterminada repita una solicitud que cambie el estado sin una estrategia de idempotencia.

Para el scraping o las pasarelas de API salientes, revisa la configuración del agente, el enrutamiento del proxy, la integración con el almacén de cookies, la descompresión y los límites de flujo. La mayor variedad de opciones de Got puede eliminar la necesidad de una infraestructura personalizada, pero aumenta la responsabilidad en la configuración. Es preferible una instancia compartida y revisada a la proliferación de opciones por cada llamada.

Las versiones actuales suelen estar documentadas como orientadas a ESM y exclusivas para Node. Confirma engines, las exportaciones, los tipos empaquetados y el estado de mantenimiento antes de elegir Got para un servicio CommonJS o un entorno de ejecución más antiguo.

Ky se sitúa a medio camino entre el Fetch nativo y un cliente HTTP completo de Node.js. Acepta entradas al estilo de Fetch al tiempo que añade atajos de métodos, instancias reutilizables, hooks y opciones de solicitud que reducen el código repetitivo. Esto lo hace atractivo cuando te gusta la semántica de Fetch pero quieres un envoltorio de aplicación más pequeño.

Se debe consultar la documentación actual para conocer el tiempo de espera exacto, los valores predeterminados de reintento, los métodos admitidos y el comportamiento ante errores. La información recopilada indica que las respuestas que no sean 2xx se consideran errores y que los reintentos están integrados de forma predeterminada; ambos aspectos pueden alterar el comportamiento al sustituir node-fetch. Conserva deliberadamente tus ramas de estado existentes en lugar de dejar que un valor predeterminado por comodidad decida por ti.

Ky delega el comportamiento importante del transporte a la implementación subyacente de Fetch. Por lo tanto, la configuración del proxy o del distribuidor, las cookies, los flujos web, FormData y HTTP/2 dependen en parte del entorno de ejecución. El progreso de la descarga se ha documentado en algunas versiones, mientras que la compatibilidad con el progreso de la subida es más limitada, así que comprueba ambos aspectos antes de diseñar la telemetría en torno a ellos.

Elige Ky entre las alternativas a node-fetch cuando la compatibilidad con Fetch sea más importante que el control del transporte específico de Node.

SuperAgent es una alternativa pragmática a Node-Fetch para equipos que prefieren una API fluida como .get(), .set(), .send(), .field(), y .attach(). Sus ayudantes para formularios y archivos hacen que los flujos de trabajo multiparte sean legibles, mientras que el análisis de respuestas integrado y las API orientadas al progreso pueden simplificar el código de carga o descarga.

La contrapartida es la distancia semántica respecto a Fetch. La gestión de errores, la configuración del tiempo de espera, las redirecciones, la cancelación y el acceso al cuerpo de la solicitud requieren un nuevo plan de pruebas, en lugar de un simple cambio de importación. La documentación original contiene afirmaciones contradictorias sobre los hooks y la compatibilidad con AbortController. Considera los plugins como complementos y comprueba si la versión que has elegido utiliza su propio método de abort, acepta señales o requiere un envoltorio.

Del mismo modo, verifica el comportamiento de los reintentos y los métodos elegibles antes de habilitarlos, y no des por sentado que HTTP/2 es una característica básica sin consultar la documentación actual. En Node.js, comprueba el comportamiento del agente, el proxy, la persistencia de cookies y el flujo de datos para tu flujo de trabajo concreto.

SuperAgent resulta más adecuado cuando sus formas encadenables y sus API de archivos sustituyen a código personalizado significativo, y no solo porque la sintaxis parezca concisa.

Una migración segura comienza por anotar la semántica existente y, a continuación, cambiar una capa cada vez. Si pasas a Fetch nativo, el cambio más pequeño que preserve el comportamiento puede ser eliminar la importación, al tiempo que se mantienen la serialización JSON explícita, las comprobaciones de estado y la cancelación.

// 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);
  }
}

Al pasar a Axios u otro cliente que lance excepciones de estado, configura su política de estado o reescribe deliberadamente el flujo de control circundante. No permitas que un error 404 pase accidentalmente de ser un resultado gestionado a una ruta de reintento genérica.

• Confirma las importaciones ESM o CommonJS y la versión mínima de Node.js desplegada.
• Compara la serialización JSON, codificada en URL, Blob, File y FormData.
• Conserva el manejo de códigos que no sean 2xx, los modos de redireccionamiento y los límites, así como las suposiciones sobre las URL absolutas.
• Verifica los tipos de error de cancelación y si los plazos cubren todo el ciclo de vida.
• Recuerda que un cuerpo consumido no se puede leer dos veces sin clonarlo o almacenarlo en el búfer.
• Convierte explícitamente los flujos de Node y los flujos web; a continuación, comprueba la contrapresión y los fallos parciales.
• Reconfigura los proxies, agentes o distribuidores, los almacenes de cookies, la descompresión y los límites de tamaño de respuesta.
• Añade pruebas de regresión para cargas, descargas de gran volumen, reintentos, protección contra POST duplicados y limpieza tras abortos.

Utiliza estos valores predeterminados de escenario para reducir las cinco alternativas de `node-fetch`:

• Servicio moderno con dependencias mínimas: empieza con Fetch nativo.
• Aplicación CommonJS heredada: mantén node-fetch v2 temporalmente o elige un cliente cuya ruta CommonJS actual y compatibilidad con Node estén verificadas.
• Código compartido entre navegador y servidor: evalúa primero Axios y, a continuación, Ky si la compatibilidad con Fetch es más importante que los interceptores.
• Integración con Node que requiere muchos reintentos: evalúa Got, con una política de idempotencia explícita.
• Formularios, archivos adjuntos y progreso de la carga: evalúa SuperAgent o Axios en función del flujo de trabajo exacto.
• Extracción de datos basada en proxy: elige en función del control del agente o del distribuidor, las cookies, la gestión de flujos y las necesidades de gestión de bloques, no solo por la sintaxis de las solicitudes.

Evalúa primero Fetch nativo en todas las versiones de Node.js que realmente admitas. Es la referencia más clara para decidir si otra dependencia merece su lugar.

Elige Axios por su comodidad en distintos entornos de ejecución, Got por sus controles avanzados de Node.js, Ky por su ergonomía al estilo de Fetch, o SuperAgent por sus flujos de trabajo encadenables de formularios y archivos. La mejor alternativa a Fetch en Node.js es aquella cuyas características integradas y verificadas sustituyan a código personalizado significativo, al tiempo que preservan tu contrato de solicitud.

• Evalúa primero el Fetch nativo cuando todas las versiones de Node.js implementadas lo admitan y solo necesites un comportamiento HTTP explícito y conforme a los estándares.
• Elige una dependencia por las comodidades verificadas que eliminen el código personalizado, no por la lista de características más extensa.
• Conserva la codificación JSON, el manejo de códigos de estado distintos de 2xx, los plazos, la cancelación, la redirección y la semántica de reintentos mediante pruebas de regresión.
• Trata los proxies, los almacenes de cookies, los tipos de flujo, las subidas de archivos y HTTP/2 como cuestiones de transporte que pueden requerir agentes, adaptadores o complementos.
• Consulta los metadatos actuales del paquete y la documentación oficial antes de confiar en formatos de módulos, límites mínimos de Node.js o valores predeterminados.

Sí, siempre que siga siendo compatible con tu entorno de ejecución, tu política de seguridad y tus expectativas de mantenimiento. Fija la versión, revisa las directrices actuales del proyecto y asegúrate de que el comportamiento de las solicitudes quede cubierto por las pruebas. Trátalo como una decisión explícita de compatibilidad, no como un valor por defecto permanente. Planifica una salida si una futura actualización de Node.js, una política de dependencias o un paquete transitivo no compatible hacen que su uso continuado resulte costoso.

La mayoría de los clientes del lado del servidor necesitan una gestión explícita de las cookies o una integración con un «cookie jar». Native Fetch y node-fetch no se comportan como un almacén de cookies de navegador. Otros clientes pueden integrarse con «cookie jars», agentes o complementos, y un agente SuperAgent persistente puede resultar útil en algunas versiones. Verifica el comportamiento relativo al dominio, la ruta, la caducidad, las redirecciones y las solicitudes simultáneas antes de confiar en la persistencia de la sesión.

No, no de forma predeterminada. Una solicitud POST que haya agotado el tiempo de espera puede haber llegado al servidor aunque el cliente nunca haya recibido una respuesta. Vuelve a intentarlo solo cuando la operación esté diseñada para la repetición, normalmente con una clave de idempotencia, una regla de deduplicación del lado del servidor o un contrato seguro específico de la aplicación. Además, limita el número de intentos y respeta las señales de retroceso del servidor cuando sea apropiado.

El cuerpo suele cambiar de un Node.js Readable a un WHATWG ReadableStream. Los .pipe() o stream.pipeline() puede que, por lo tanto, sea necesario convertirlo, por ejemplo, Readable.fromWeb() cuando sea compatible, o un canal de transmisión web. Comprueba la contrapresión, la propagación de abortos, los archivos parciales, la descompresión y la limpieza, ya que las pruebas exitosas con búferes pequeños pueden no revelar fallos en la transmisión en producción.

La elección adecuada entre las alternativas a node-fetch depende del comportamiento que se desee conservar y de la infraestructura que ya no se quiera mantener. Native Fetch es la opción básica más sensata para los entornos de ejecución compatibles, ya que elimina una dependencia al tiempo que mantiene la semántica habitual de Fetch. Axios añade transformaciones e interceptores entre entornos de ejecución, Got hace hincapié en los controles detallados de Node.js, Ky envuelve Fetch con funciones prácticas y SuperAgent hace que los flujos de trabajo de formularios y archivos sean legibles.

Antes de cambiar, haz un inventario de los requisitos de cada solicitud. Comprueba las importaciones, la serialización JSON, el manejo de códigos de respuesta distintos de 2xx, los plazos, la cancelación, la posibilidad de reintentos, las redirecciones, la persistencia de cookies, el enrutamiento por proxy, las subidas de archivos y los tipos de flujo. A continuación, verifica los requisitos actuales del paquete y los valores predeterminados con respecto a la versión principal exacta que pretendes instalar.

En el caso de las tareas de scraping, el cliente HTTP puede ser solo una de las capas del problema. Si los bloqueos, los CAPTCHAs y la rotación de proxies suponen más esfuerzo que el manejo de las respuestas, plantéate utilizar la API Scraper de WebScrapingAPI. Devuelve HTML sin procesar mientras se encarga de esa capa de solicitud. Mantén el análisis y la lógica de negocio en tu aplicación, y utiliza el cliente que haga más claras esas responsabilidades restantes.