Client Caching

What it is

The shieldbow client has a built-in caching system.

Caching systems are intended to store data in the memory to avoid fetching the same data multiple times.

The shieldbow cache serves three primary purposes.

  1. To cache the processed JS objects of the data dragon files.
  2. To cache the data fetched from the APIs.
  3. To keep track of the rate limits.
IMPORTANT

The cache is not intended to be used as a storage system.
NOTE

Shieldbow sends processed JS objects to the cache, not the raw JSON data.

The only exception to this is the ratelimits, which instead sends an array of numbers.

How does it work

By default, shieldbow provides a built-in cache that stores the data in memory. Some helpful links to learn more about this cache system:

Whenever you make a request to one of the APIs, the client will

  1. Check if caching is enabled.
  2. Check if the data is already cached.
  3. If it is, it will return the cached data.
  4. If not, it will proceed to storage.

Since storage is not a concern of this document, you can think of it as a way to fetch the data from the APIs.

The defaults

By default, the client will cache all data it fetches, from both the data dragon, and the RIOT APIs.

This can be changed by setting the cache option to false when initializing the client. You can set it to true to enable caching, or to an object to customize the cache. The object can be fine-tuned to a per-API basis.

client.initialize({  cache: {    enable: {      api: { // API caching        summoner: true, // Enable or disable caching for the summoner API        match: true, // Enable or disable caching for the match API        // ... so on      },      dragon: {        champions: true, // Enable or disable caching for the champions data dragon        items: true, // Enable or disable caching for the items data dragon        // ... so on      }    } // Enable or disable caching  }})

For quicker access, you can simply set api or dragon to true or false to enable or disable caching for all APIs or data dragon data respectively.

This can be used at any level in the object.

Custom cache

As you can see, the default cache is a simple in-memory cache. This is not ideal for production environments, as the data will be lost when the process is restarted.

To solve this, you can provide your own cache system by implementing the ICache interface.

import { ICache } from 'shieldbow'class MyCache implements ICache {  // ...}
The keys

As you can see, the cache interface has a get and a set method that take a key and a value as parameters.

The key is a string that is used to identify the data in the cache. The value is the data that is stored in the cache.

The key is generated by the client, and is unique for each API and data dragon data.

The keys are generated using the following format:

  `${managerName}:${id}`

Where managerName is the name of the manager that is fetching the data, and id is the id of the data. Some common examples for managerName are summoner, match, champion, item, etc.

The id is the id of the data that is being fetched. For example, if you are fetching the data for the champion Aatrox, the id will be Aatrox.

The values are always a JS object based on one of the shieldbow classes (e.g. a Summoner object).

There is an exception to the rule for values, which is the ratelimits.

This is discussed in the Ratelimits section.

No cache

Because shieldbow needs a cache to be able to keep track of the ratelimits, you cannot disable caching completely.

However, you can disable caching for all the fetched data from RIOT APIs or data dragon.

This will lead to the client not caching any data, but still keeping track of the ratelimits.

Edit this page on GitHub
Table of Contents