Rate limiting

As of now, the client can handle rate limiting automatically.

This is done by storing the rate limit information in memory using the cache.

The shieldbow v2 client can actually handle rate limits very well, even without having a shared cache. As it relies on the response headers, it can process the rate limit information and update its own cache accordingly.

This way, you can use the client in a distributed environment, and it will still work. Even without a shared cache!

Customization

By providing some RateLimiterOptions, you can customize the rate limiter.

Some useful options are:

1. retry (object): The retrying options, the client will only retry if the original request timed out.
   1. retries (number): The number of times to retry the request (default = 0).
   2. retryDelay (number): The delay between each retry in ms (default = 3000).
2. throw (boolean): Whether to throw an error when the rate limit is reached (default = true). If set to false, the client will delay the request until the rate limit is reset and send the request.
3. strategy (string): The strategy to use when the rate limit is reached.
   1. burst (default): The client will send the request immediately.
   2. spread: The client will calculate appropriate amount of delay for the request to avoid being ratelimited.

Example

const client = new ShieldbowClient();client.initialize({  ratelimiter: {    retry: {      retries: 3,      retryDelay: 5000,    },    throw: false,    strategy: 'spread',  },});

Custom Limits

Shieldbow also provides a way to set custom rate limits.

While I originally got a production API key, for some reason, I was not getting the rate limit headers.

This is a bug on RIOT's end, and was fixed eventually. However, if you face the same issue, you can use the fixed rate limits.

Simply provide appLimit and methodLimit options for the ratelimiter config during initialization.

As a saving grace, however, these will automatically be overwritten by the response headers.