Client Storage

What it is

The shieldbow client has a built-in storage system.

Storage systems are intended to store data on disks to avoid fetching the same data multiple times.

The shieldbow storage serves two primary purposes.

  1. To relieve the API servers from unnecessary requests.
  2. To avoid caching too much data as memory is a lot more limited than disk space.
NOTE

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

How does it work

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

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

  1. Check caching.
  2. Check if storage is enabled.
  3. Check if the data is already stored.
  4. If it is, it will return the stored data.
  5. If not, it will proceed to fetching the data from the APIs.

The defaults

By default, the client will store all data dragon files, but not the data fetched from RIOT APIs.

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

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

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

Defaults to { dragon: true, api: false }.

This can be used at any level in the object.


Custom storage

As you can see, the default storage is a simple a JSON files storage medium. This is not ideal for production environments.

To solve this, you can provide your own storage system by implementing the IStorage interface.

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

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

The key is a unique identifier for the type and version of the object. The id is the id of the data that is being fetched. The value is the data that is stored in the storage.

The keys are generated using the following format can contain many values separated by a :.

`${managerName}:${version}?:${source}?:${locale}?`

is the format for champion data.

Where managerName is the name of the manager that is fetching the data, version is the patch version, source is the source of the data (e.g. riot or ddragon) and locale is the locale 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 JSON object based on one of the shieldbow interfaces (e.g. a SummonerData object).


Caveats

The storage system can use up a LOT of disk space.

To solve, this you can make a custom storage system that only saves the data you need, this however would lead to another problem as the storage system cannot fetch data from storage if the entire object is not stored.

In these cases, in your custom storage, you can simply return a Promise.reject to indicate that the data is not stored, and the client will fetch the data from the APIs as a workaround.