retry-request vs fetch-retry vs axios-retry vs retry-axios vs superagent-retry
HTTP Request Retry Libraries Comparison
1 Year
retry-requestfetch-retryaxios-retryretry-axiossuperagent-retrySimilar Packages:
What's HTTP Request Retry Libraries?

These libraries provide mechanisms to automatically retry failed HTTP requests in JavaScript applications. They are particularly useful for handling transient errors, such as network issues or server timeouts, ensuring that applications can recover gracefully from temporary failures. By implementing retries, developers can enhance the reliability of their applications and improve user experience by reducing the likelihood of failure due to intermittent issues.

Package Weekly Downloads Trend
Github Stars Ranking
Stat Detail
Package
Downloads
Stars
Size
Issues
Publish
License
retry-request7,865,4146721.2 kB27 days agoMIT
fetch-retry3,980,10630955.2 kB3a year agoMIT
axios-retry3,803,8621,93033.6 kB517 months agoApache-2.0
retry-axios886,92849436.4 kB34a year agoApache-2.0
superagent-retry14,43085-109 years ago-
Feature Comparison: retry-request vs fetch-retry vs axios-retry vs retry-axios vs superagent-retry

Integration

  • retry-request:

    retry-request is built for the request library, making it easy to add retry functionality to Node.js applications. It is straightforward to use and integrates well with the request library's API, making it suitable for server-side applications.

  • fetch-retry:

    fetch-retry is designed to work with the native Fetch API, providing a simple wrapper that adds retry capabilities. It is lightweight and does not require any additional dependencies, making it a good fit for modern web applications that use Fetch.

  • axios-retry:

    axios-retry integrates directly with Axios, allowing you to add retry logic with minimal configuration. It leverages Axios interceptors to handle retries seamlessly, making it easy to implement in existing Axios-based projects.

  • retry-axios:

    retry-axios extends the functionality of Axios by providing additional features like customizable retry strategies and error handling. It is built specifically for Axios users who need more control over the retry process, allowing for advanced configurations.

  • superagent-retry:

    superagent-retry is specifically designed for SuperAgent, allowing users to add retry logic to their HTTP requests easily. It fits well within the SuperAgent ecosystem, providing a seamless experience for users of that library.

Customization

  • retry-request:

    retry-request provides basic customization options, allowing users to set the number of retries and delay. It is straightforward but lacks the advanced features found in other libraries.

  • fetch-retry:

    fetch-retry provides basic customization options, such as the number of retries and delay between attempts. However, it is less flexible compared to other libraries, focusing on simplicity and ease of use.

  • axios-retry:

    axios-retry allows for extensive customization of retry strategies, including the ability to specify the number of retries, delay between retries, and conditions under which retries should occur. This flexibility makes it suitable for various use cases.

  • retry-axios:

    retry-axios offers advanced customization options, including exponential backoff strategies and the ability to define custom retry conditions based on response status codes or error types. This makes it a powerful choice for complex applications.

  • superagent-retry:

    superagent-retry allows for some customization, including the number of retries and delay between attempts. It is designed to be simple and effective without overwhelming users with options.

Error Handling

  • retry-request:

    retry-request provides basic error handling, retrying on network errors and certain HTTP status codes. It is straightforward but may require additional handling for more complex scenarios.

  • fetch-retry:

    fetch-retry has basic error handling, retrying on network errors and certain HTTP status codes. However, it may not cover all edge cases, requiring developers to implement additional logic for comprehensive error handling.

  • axios-retry:

    axios-retry provides built-in error handling capabilities, allowing users to define specific conditions under which retries should occur. This ensures that only appropriate errors trigger a retry, improving the reliability of the application.

  • retry-axios:

    retry-axios excels in error handling by allowing users to specify custom conditions for retries based on response status codes and error types. This level of control helps ensure that retries are only attempted when appropriate, enhancing application stability.

  • superagent-retry:

    superagent-retry offers basic error handling, retrying on network errors and specific HTTP status codes. It is simple to use but may not cover all scenarios, requiring additional logic for comprehensive error handling.

Performance Impact

  • retry-request:

    retry-request has a low performance impact, as it only retries failed requests. However, like other libraries, excessive retries can lead to performance degradation in high-load situations.

  • fetch-retry:

    fetch-retry is lightweight and has a low performance impact, making it ideal for applications that prioritize speed and efficiency. However, excessive retries may still affect performance in high-load scenarios.

  • axios-retry:

    axios-retry has minimal performance impact, as it only retries failed requests without adding significant overhead. This makes it suitable for applications where performance is critical, and retries are infrequent.

  • retry-axios:

    retry-axios is designed to minimize performance impact while providing robust retry capabilities. It uses efficient algorithms to manage retries, ensuring that applications remain responsive even under load.

  • superagent-retry:

    superagent-retry is lightweight and has minimal performance overhead, making it suitable for applications where performance is a concern. It efficiently manages retries without introducing significant delays.

Learning Curve

  • retry-request:

    retry-request is simple to learn and implement, especially for those already using the request library. Its straightforward API allows for quick integration into existing projects.

  • fetch-retry:

    fetch-retry is easy to learn, particularly for developers accustomed to the Fetch API. Its simplicity and minimal configuration requirements make it accessible to newcomers.

  • axios-retry:

    axios-retry has a gentle learning curve, especially for developers already familiar with Axios. Its straightforward API and integration make it easy to implement without extensive documentation.

  • retry-axios:

    retry-axios may have a slightly steeper learning curve due to its advanced features and customization options. However, developers familiar with Axios will find it manageable.

  • superagent-retry:

    superagent-retry has a low learning curve for developers familiar with SuperAgent. Its integration is seamless, making it easy to add retry functionality without extensive setup.

How to Choose: retry-request vs fetch-retry vs axios-retry vs retry-axios vs superagent-retry
  • retry-request:

    Use retry-request if you are working with the request library and need a straightforward way to implement retries. It is designed for Node.js applications and is perfect for server-side HTTP requests, providing a simple API for retrying requests.

  • fetch-retry:

    Select fetch-retry if you are using the Fetch API and want a lightweight solution to add retry capabilities. It is ideal for projects that prefer native browser APIs and need minimal overhead, making it a good choice for modern web applications.

  • axios-retry:

    Choose axios-retry if you are already using Axios for making HTTP requests and need a simple way to add retry functionality without changing your existing code structure significantly. It integrates seamlessly with Axios and allows for customizable retry strategies.

  • retry-axios:

    Opt for retry-axios if you want to extend Axios with more advanced retry capabilities, including exponential backoff strategies and better error handling. This package is suitable for applications that require more control over the retry process and need to handle various error types effectively.

  • superagent-retry:

    Choose superagent-retry if you are utilizing the SuperAgent library for making HTTP requests and need to add retry logic. This package is tailored for SuperAgent users and provides a clean integration for retrying failed requests.

README for retry-request

THIS REPOSITORY AND PACKAGE WILL BE DEPRECATED IN JULY 2024. RELEVANT FUNCTIONALITIES HAVE BEEN MOVED TO GOOGLEAPIS/GAXIOS

|retry-request |:-: |Retry a request with built-in exponential backoff.

$ npm install --save teeny-request
$ npm install --save retry-request
var request = require('retry-request', {
  request: require('teeny-request'),
});

It should work the same as request and teeny-request in both callback mode and stream mode.

Note: This module only works when used as a readable stream, i.e. POST requests aren't supported (#3).

Do I need to install request?

Yes! You must independently install teeny-request OR request (deprecated) and provide it to this library:

var request = require('retry-request', {
  request: require('teeny-request'),
});

Callback

urlThatReturns503 will be requested 3 total times before giving up and executing the callback.

request(urlThatReturns503, function (err, resp, body) {});

Stream

urlThatReturns503 will be requested 3 total times before giving up and emitting the response and complete event as usual.

request(urlThatReturns503)
  .on('error', function () {})
  .on('response', function () {})
  .on('complete', function () {});

Can I monitor what retry-request is doing internally?

Yes! To enable the debug mode, set the environment variable DEBUG to retry-request.

(Thanks for the implementation, @yihaozhadan!)

request(requestOptions, [opts], [cb])

requestOptions

Passed directly to request or teeny-request. See the list of options supported:

  • https://github.com/request/request/#requestoptions-callback
  • https://github.com/googleapis/teeny-request#teenyrequestoptions-callback

opts (optional)

opts.noResponseRetries

Type: Number

Default: 2

The number of times to retry after a response fails to come through, such as a DNS resolution error or a socket hangup.

var opts = {
  noResponseRetries: 0,
};

request(url, opts, function (err, resp, body) {
  // url was requested 1 time before giving up and
  // executing this callback.
});

opts.objectMode

Type: Boolean

Default: false

Set to true if your custom opts.request function returns a stream in object mode.

opts.retries

Type: Number

Default: 2

var opts = {
  retries: 4,
};

request(urlThatReturns503, opts, function (err, resp, body) {
  // urlThatReturns503 was requested a total of 5 times
  // before giving up and executing this callback.
});

opts.currentRetryAttempt

Type: Number

Default: 0

var opts = {
  currentRetryAttempt: 1,
};

request(urlThatReturns503, opts, function (err, resp, body) {
  // urlThatReturns503 was requested as if it already failed once.
});

opts.shouldRetryFn

Type: Function

Default: Returns true if http.incomingMessage.statusCode is < 200 or >= 400.

var opts = {
  shouldRetryFn: function (incomingHttpMessage) {
    return incomingHttpMessage.statusMessage !== 'OK';
  },
};

request(urlThatReturnsNonOKStatusMessage, opts, function (err, resp, body) {
  // urlThatReturnsNonOKStatusMessage was requested a
  // total of 3 times, each time using `opts.shouldRetryFn`
  // to decide if it should continue before giving up and
  // executing this callback.
});

opts.request

Type: Function

If we not provided we will throw an error advising you to provide it.

NOTE: If you override the request function, and it returns a stream in object mode, be sure to set opts.objectMode to true.

var originalRequest = require('teeny-request').defaults({
  pool: {
    maxSockets: Infinity,
  },
});

var opts = {
  request: originalRequest,
};

request(urlThatReturns503, opts, function (err, resp, body) {
  // Your provided `originalRequest` instance was used.
});

opts.maxRetryDelay

Type: Number

Default: 64

The maximum time to delay in seconds. If retryDelayMultiplier results in a delay greater than maxRetryDelay, retries should delay by maxRetryDelay seconds instead.

opts.retryDelayMultiplier

Type: Number

Default: 2

The multiplier by which to increase the delay time between the completion of failed requests, and the initiation of the subsequent retrying request.

opts.totalTimeout

Type: Number

Default: 600

The length of time to keep retrying in seconds. The last sleep period will be shortened as necessary, so that the last retry runs at deadline (and not considerably beyond it). The total time starting from when the initial request is sent, after which an error will be returned, regardless of the retrying attempts made meanwhile.

cb (optional)

Passed directly to request. See the callback section: https://github.com/request/request/#requestoptions-callback.