Comparaison de 5 alternatives à node-fetch : Native Fetch, Axios, Got, Ky et SuperAgent

Il n’y a pas de solution universelle parmi les alternatives à node-fetch. Commencez par déterminer les fonctionnalités dont votre application a réellement besoin, puis vérifiez la version majeure installée et la version de base de Node.js.

Ces choix se répartissent en trois catégories : une API d’exécution, un wrapper Fetch et des clients HTTP complets. Comparez au sein de la bonne catégorie plutôt que de considérer chaque lacune en matière de fonctionnalités comme un défaut.

Considérez cette décision comme un choix entre conserver, supprimer ou remplacer. Conservez node-fetch lorsque son comportement actuel est couvert par des tests, que vos contraintes d’exécution le justifient et que la migration n’apporte aucun avantage opérationnel concret. Supprimez-le lorsque les versions de Node.js que vous prenez en charge exposent déjà Fetch en tant que variable globale et que votre code n’a besoin que de requêtes conformes aux normes. Remplacez-le lorsque les tentatives de reconnexion, les hooks, les délais d’expiration par phases, les transformations centralisées ou les aides au téléchargement deviennent une infrastructure gérée par l’application.

Un guide pratique sur la réalisation de requêtes HTTP avec node-fetch peut encore s’avérer utile lorsque vous assurez la maintenance d’une intégration existante. Ce package n’est pas automatiquement un mauvais choix simplement parce que les environnements d’exécution plus récents intègrent Fetch. La question pertinente est de savoir si une autre option réduit les risques ou allège le code sans modifier silencieusement la sémantique.

Fetch natif réduit la surface de dépendance et aligne le code serveur sur le modèle standardisé Request, Response, Headers et Body. La documentation officielle globale de Fetch pour Node.js consigne l’historique de ses versions et de sa stabilité ; vous devez la vérifier par rapport au runtime exact déployé en production.

Ne vous fiez pas à un délai d’expiration supposé de la plateforme. Définissez un délai explicite avec AbortController, ou utilisez AbortSignal.timeout() uniquement après avoir vérifié que l’API existe dans toutes les versions prises en charge de Node.js.

La documentation de node-fetch capturée décrit la v3 comme étant réservée à ESM et la v2 comme étant compatible avec CommonJS. Elle mentionne également des déclarations TypeScript intégrées pour la v3 et une version minimale plus ancienne de Node.js, mais ces détails et ces conseils de maintenance sont sensibles au facteur temps. Vérifiez les métadonnées du paquet avant d’opter pour l’une ou l’autre de ces versions.

Procédez de la même manière pour Axios, Got, Ky et SuperAgent. Vérifiez engines, type, exports, et types avec npm view <package> engines type exports types, puis testez la forme d’importation effective en CI. Les versions majeures actuelles peuvent présenter des différences en matière de prise en charge d’ESM, d’interopérabilité avec CommonJS et d’exigences d’exécution.

Utilisez ce tableau comme liste de présélection. B signifie « intégré », A « module complémentaire ou adaptateur » et M « code d’application manuel ». Un astérisque indique une fonctionnalité sensible au moment de la mise en œuvre qui nécessite une vérification spécifique à chaque version.

La liste de fonctionnalités la plus longue est rarement le meilleur critère. Définissez le contrat de requête : encodage du corps, erreurs de statut, délais, tentatives de réessai et type de flux transmis en aval. Un choix parmi les alternatives de récupération de nœuds n’est sûr que lorsque ces comportements restent intentionnels.

Ce guide exclut les classements de vitesse, les nombres de téléchargements, les étoiles, les allégations concernant la taille des paquets et les classements de maintenance. Sans mesures récentes, sans dates et sans méthode clairement définie, ces chiffres donnent une fausse impression de précision plutôt que de permettre une décision technique éclairée.

Les clients de type « fetch » nécessitent généralement des JSON.stringify(), des en-têtes de contenu, l’analyse des réponses et des response.ok . Axios transforme les charges utiles des objets, expose le contenu analysé sur response.dataet rejette par défaut les réponses autres que 2xx, sauf si validateStatus modifie cette règle. Cette différence peut entraîner le déplacement du code d’une branche normale vers catch.

Définissez explicitement les délais, quel que soit le client. Distinguez le délai total de la requête des phases de connexion, TLS, premier octet et socket. Les tentatives de réessai doivent également faire l’objet d’une politique écrite. Réessayer une requête GET après un échec transitoire est différent de réitérer une requête POST qui a peut-être déjà été validée. Considérez la prise en charge des réessais automatiques comme un moteur de politique, et non comme une simple case à cocher.

Pour les services Node.js et le scraping, les détails de transport déterminent souvent le client. La prise en charge des proxys peut provenir d’une option client, d’un agent HTTP, d’un dispatcher Fetch ou d’un adaptateur. La persistance des cookies nécessite généralement un fichier JAR ou une logique d’application, car les clients côté serveur n’héritent pas du magasin de cookies du navigateur.

Vérifiez si les corps de réponse sont des flux Node.js Readable ou des objets WHATWG ReadableStream avant de modifier les pipelines de téléchargement. Vérifiez le comportement des FormData multipart, les limites de taille des fichiers, la gestion des redirections, la décompression et la contre-pression. La prise en charge de HTTP/2 peut relever du client, d’une extension ou du runtime sous-jacent.

Un guide pratique sur la configuration des proxys dans node-fetch et un guide plus général sur le web scraping avec JavaScript et Node.js constituent des compléments naturels lorsque ces enjeux liés au transport dominent la migration.

Pour les environnements d’exécution pris en charge, le Fetch natif devrait constituer la première référence par rapport à laquelle évaluer les autres alternatives à node-fetch. Il conserve l’interface familière basée sur les promesses sans recourir à un paquet client externe, mais il préserve également l’explicité délibérée de Fetch : vous sérialisez le JSON, analysez le corps de la réponse et déterminez vous-même la signification d’une erreur 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);
}

Cet exemple définit son propre délai plutôt que de se baser sur une valeur par défaut non documentée. Une défaillance réseau ou une annulation rejette la « promise », tandis qu’un code d’erreur 404 ou 500 produit toujours une réponse (« Response ») que votre code doit analyser. Ce comportement est conforme à la norme Fetch au sens large.

Le principal piège de la migration réside dans les flux. node-fetch expose des corps lisibles par Node.js, tandis que Fetch natif suit la sémantique des flux Web. Si le code existant achemine directement le contenu vers stream.pipeline, adaptez ou convertissez le corps de la réponse et effectuez des tests de régression sur la contre-pression, l’annulation et la propagation des erreurs.

Axios constitue une alternative solide à `node-fetch` lorsque la commodité doit être centralisée entre le code du navigateur et celui du serveur. Le fait de passer un simple objet comme données de requête déclenche la sérialisation JSON et la gestion appropriée du contenu, et les données de réponse analysées sont disponibles via response.data. Par défaut, les statuts autres que 2xx sont traités comme des erreurs avec les détails du serveur sur error.response.

Les instances réutilisables vous permettent de standardiser les URL de base, les en-têtes, les délais et validateStatus. Les intercepteurs sont des middlewares intégrés destinés à l’authentification, au traçage, à la journalisation, aux flux de rafraîchissement et à la transformation des réponses. Ils peuvent remplacer le code de wrapper répétitif, mais peuvent également masquer certains comportements ; veillez donc à tester l’ordre des intercepteurs et les chemins d’échec.

Les tentatives de réessai ne font pas partie du cœur d’Axios dans les preuves capturées. Ajoutez-les via une extension ou une politique d’application, et vérifiez les méthodes éligibles. Le comportement du proxy peut dépendre du protocole, des variables d’environnement, des adaptateurs ou des agents personnalisés ; testez donc le chemin de déploiement exact plutôt que de supposer qu’une seule option de proxy couvre tous les cas.

Un guide de configuration dédié au proxy Axios et un guide pratique sur les en-têtes Axios constituent des ressources internes utiles à consulter. Vérifiez également la version minimale de Node.js requise par le package actuel, les exportations de modules, l’API d’annulation, le comportement des flux et tout adaptateur HTTP/2 avant de valider le déploiement.

Got est l’option la plus axée sur Node.js parmi cet ensemble d’alternatives à node-fetch. Son atout réside dans le contrôle : des phases de délai d’expiration distinctes peuvent couvrir la recherche DNS, la connexion, la négociation TLS, l’envoi de la requête, le premier octet de réponse, l’inactivité du socket ou l’ensemble du cycle de vie. Cela rend la télémétrie des échecs plus exploitable qu’un simple délai d’expiration générique.

Got expose également des hooks et des API de streaming adaptés aux intégrations de service à service. La documentation fournie décrit les réessais automatiques avec backoff, le respect de Retry-Afteret la prise en charge native de HTTP/2, mais les valeurs par défaut, les méthodes éligibles et le comportement actuel du transport doivent être vérifiés pour la version majeure installée. Ne laissez jamais une politique de réessai par défaut réitérer une requête modifiant l’état sans stratégie d’idempotence.

Pour le scraping ou les passerelles API sortantes, vérifiez la configuration des agents, le routage par proxy, l’intégration du cookie-jar, la décompression et les limites de flux. L’interface d’options plus riche de Got peut supprimer le besoin d’une infrastructure personnalisée, mais elle accroît la responsabilité en matière de configuration. Privilégiez une instance partagée et validée plutôt qu’une prolifération d’options par appel.

Les versions actuelles sont généralement documentées comme étant orientées ESM et réservées à Node. Vérifiez engines, les exportations, les types intégrés et l’état de maintenance avant de choisir Got pour un service CommonJS ou un runtime plus ancien.

Ky se situe à mi-chemin entre Fetch natif et un client HTTP Node.js complet. Il accepte les entrées de type Fetch tout en ajoutant des raccourcis de méthode, des instances réutilisables, des hooks et des options de requête qui réduisent le code répétitif. Cela le rend intéressant lorsque vous appréciez la sémantique de Fetch mais souhaitez un wrapper d’application plus léger.

Il convient de consulter la documentation actuelle pour connaître le délai d’expiration exact, les valeurs par défaut des réessais, les méthodes prises en charge et le comportement en cas d’erreur. Les informations recueillies indiquent que les réponses autres que 2xx sont considérées comme des erreurs et que les réessais sont intégrés par défaut ; ces deux aspects peuvent modifier le comportement lors du remplacement de node-fetch. Préservez délibérément vos branches de statut existantes plutôt que de laisser une valeur par défaut de commodité décider à votre place.

Ky délègue les comportements de transport importants à l’implémentation sous-jacente de Fetch. La configuration du proxy ou du répartiteur, les cookies, les flux Web, FormData et HTTP/2 dépendent donc en partie de l’environnement d’exécution. La progression des téléchargements a été documentée dans certaines versions, tandis que la prise en charge de la progression des chargements est plus limitée ; vérifiez donc ces deux aspects avant de concevoir une télémétrie autour d’eux.

Optez pour Ky parmi les alternatives à node-fetch lorsque la compatibilité avec Fetch prime sur le contrôle du transport spécifique à Node.

SuperAgent est une alternative pragmatique à Node-Fetch pour les équipes qui préfèrent une API fluide telle que .get(), .set(), .send(), .field(), et .attach(). Ses aides pour les formulaires et les fichiers rendent les workflows multipart lisibles, tandis que l’analyse intégrée des réponses et les API orientées progression peuvent simplifier le code de téléchargement ou de chargement.

En contrepartie, il existe un écart sémantique par rapport à Fetch. La gestion des erreurs, la configuration des délais d’expiration, les redirections, l’annulation et l’accès au corps de la requête nécessitent un nouveau plan de test plutôt qu’un simple remplacement d’import. La documentation source contient des informations contradictoires concernant les hooks et la prise en charge d’AbortController. Considérez les plugins comme des extensions et vérifiez si la version que vous avez choisie utilise sa propre méthode d’annulation, accepte les signaux ou nécessite un wrapper.

De même, vérifiez le comportement des tentatives de réessai et les méthodes éligibles avant de l’activer, et ne partez pas du principe que HTTP/2 est intégré sans documentation à jour. Dans Node.js, examinez le comportement de l’agent, du proxy, de la persistance des cookies et des flux pour votre workflow précis.

SuperAgent est particulièrement adapté lorsque ses formes chaînables et ses API de fichiers remplacent du code personnalisé pertinent, et non pas simplement parce que la syntaxe semble concise.

Une migration sûre commence par la description de la sémantique existante, puis par la modification d’une couche à la fois. Si vous passez à Fetch natif, le changement le plus mineur préservant le comportement peut consister à supprimer l’import tout en conservant la sérialisation JSON explicite, les vérifications d’état et l’annulation.

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

Lorsque vous passez à Axios ou à un autre client générant des statuts d’erreur, configurez sa politique de gestion des statuts ou réécrivez délibérément le flux de contrôle environnant. Ne laissez pas un code d’erreur 404 passer accidentellement d’un résultat géré à un chemin de réessai générique.

• Vérifiez les importations ESM ou CommonJS ainsi que la version minimale de Node.js déployée.
• Comparez les sérialisations JSON, encodées en URL, Blob, File et FormData.
• Conservez la gestion des codes d’erreur autres que 2xx, les modes de redirection et les limites, ainsi que les hypothèses relatives aux URL absolues.
• Vérifiez les types d’erreurs d’annulation et assurez-vous que les délais couvrent l’ensemble du cycle de vie.
• N’oubliez pas qu’un corps déjà consommé ne peut pas être lu deux fois sans clonage ni mise en mémoire tampon.
• Convertissez explicitement les flux Node et les flux Web, puis testez la contre-pression et les échecs partiels.
• Reconfigurez les proxys, les agents ou les répartiteurs, les pots de cookies, la décompression et les limites de taille des réponses.
• Ajoutez des tests de régression pour les envois, les téléchargements volumineux, les nouvelles tentatives, la protection contre les requêtes POST en double et le nettoyage après les interruptions.

Utilisez ces paramètres par défaut pour affiner les cinq alternatives à `node-fetch` :

• Service moderne à dépendances minimales : commencez avec Fetch natif.
• Application CommonJS héritée : conservez temporairement node-fetch v2 ou choisissez un client dont le chemin CommonJS actuel et la base Node sont vérifiés.
• Code partagé entre navigateur et serveur : évaluez d’abord Axios, puis Ky si la compatibilité avec Fetch est plus importante que les intercepteurs.
• Intégration Node nécessitant de nombreuses tentatives : évaluez Got, avec une politique d’idempotence explicite.
• Formulaires, pièces jointes et progression des téléchargements : évaluez SuperAgent ou Axios en fonction du workflow précis.
• Scraping via proxy : faites votre choix en fonction du contrôle de l’agent ou du répartiteur, des cookies, de la gestion des flux et des besoins en matière de gestion des blocs, et non pas uniquement en fonction de la syntaxe des requêtes.

Évaluez d’abord Fetch natif sur chaque version de Node.js que vous prenez réellement en charge. C’est la référence la plus claire pour déterminer si une autre dépendance mérite sa place.

Optez pour Axios pour sa facilité d’utilisation sur plusieurs environnements d’exécution, Got pour un contrôle approfondi de Node.js, Ky pour une ergonomie de type Fetch, ou SuperAgent pour des workflows enchaînables de formulaires et de fichiers. La meilleure alternative à Node Fetch est celle dont les fonctionnalités intégrées et éprouvées remplacent un code personnalisé pertinent tout en préservant votre contrat de requête.

• Évaluez d’abord la fonction native `Fetch` lorsque toutes les versions de Node.js déployées la prennent en charge et que vous n’avez besoin que d’un comportement HTTP explicite et conforme aux normes.
• Choisissez une bibliothèque pour ses fonctionnalités éprouvées qui éliminent le code personnalisé, et non pour la liste de fonctionnalités la plus longue.
• Préservez l’encodage JSON, la gestion des codes d’état autres que 2xx, les délais, l’annulation, la redirection et la sémantique des réessais à l’aide de tests de régression.
• Considérez les proxys, les pots de cookies, les types de flux, les téléchargements et HTTP/2 comme des aspects liés au transport pouvant nécessiter des agents, des adaptateurs ou des plugins.
• Vérifiez les métadonnées actuelles des paquets et la documentation officielle avant de vous fier aux formats de modules, aux limites de Node.js ou aux valeurs par défaut.

Oui, à condition qu’il reste compatible avec votre environnement d’exécution, votre politique de sécurité et vos attentes en matière de maintenance. Fixez la version, consultez les recommandations actuelles pour le projet et assurez-vous que le comportement des requêtes est couvert par des tests. Considérez cela comme un choix de compatibilité explicite, et non comme une valeur par défaut permanente. Prévoyez une solution de rechange si une future mise à jour de Node.js, une politique de dépendances ou un paquet transitif non pris en charge rendait son utilisation continue trop coûteuse.

La plupart des clients côté serveur nécessitent une gestion explicite des cookies ou une intégration à un « cookie jar ». Native Fetch et node-fetch ne se comportent pas comme un magasin de cookies de navigateur. D’autres clients peuvent s’intégrer à des « cookie jars », des agents ou des plugins, et un agent SuperAgent persistant peut s’avérer utile dans certaines versions. Vérifiez le comportement en matière de domaine, de chemin d’accès, d’expiration, de redirection et de requêtes simultanées avant de vous fier à la persistance de session.

Non, pas par défaut. Une requête POST ayant expiré peut avoir atteint le serveur même si le client n’a jamais reçu de réponse. Ne la réessayez que lorsque l’opération est conçue pour être rejouée, généralement avec une clé d’idempotence, une règle de déduplication côté serveur ou un contrat spécifique à l’application garantissant la sécurité. Limitez également le nombre de tentatives et respectez les signaux de recul du serveur lorsque cela est approprié.

Le corps passe généralement d’un format Node.js Readable à un format WHATWG ReadableStream. Les .pipe() ou stream.pipeline() code existant peut donc nécessiter une conversion, par exemple Readable.fromWeb() lorsque cela est pris en charge, ou un pipeline de flux Web. Testez la contre-pression, la propagation des interruptions, les fichiers partiels, la décompression et le nettoyage, car des tests réussis avec de petits tampons peuvent ne pas révéler les défaillances de streaming en production.

Le choix approprié parmi les alternatives à node-fetch dépend du comportement que vous souhaitez conserver et de l’infrastructure que vous ne souhaitez plus maintenir. Native Fetch constitue la base de référence judicieuse pour les environnements d’exécution pris en charge, car il supprime une dépendance tout en conservant la sémantique familière de Fetch. Axios ajoute des transformations et des intercepteurs inter-environnements d’exécution, Got met l’accent sur des contrôles détaillés de Node.js, Ky encapsule Fetch avec des fonctionnalités pratiques, et SuperAgent rend lisibles les workflows liés aux formulaires et aux fichiers.

Avant de changer de solution, dressez l’inventaire des contraintes liées à chaque requête. Vérifiez les importations, la sérialisation JSON, la gestion des codes d’état autres que 2xx, les délais, l’annulation, les conditions de réessai, les redirections, la persistance des cookies, le routage par proxy, les téléchargements et les types de flux. Vérifiez ensuite les exigences et les paramètres par défaut actuels du package par rapport à la version majeure exacte que vous comptez installer.

Pour les tâches de scraping, le client HTTP n’est peut-être qu’une couche du problème. Si les blocages, les CAPTCHA et la rotation des proxys demandent plus d’efforts que la gestion des réponses, envisagez l’API Scraper de WebScrapingAPI. Elle renvoie du HTML brut tout en gérant cette couche de requête. Conservez le parsing et la logique métier au sein de votre application, et choisissez le client qui clarifie le mieux ces responsabilités restantes.