-
Notifications
You must be signed in to change notification settings - Fork 2
Description
While caching isn't generally recommended in an API, there are values that do not need to be fetched multiple times as they are written into the chain history.
With that in mind, there are a few strategies that could be deployed here, and Workers KV should be a great match for the task. It supports very high read volumes and would reduce load on the main API.
The KV objects could be named in the format: {city}-{datapoint}, e.g.
mia-activationblockmia-miningstatsatblockmia-stackingstatsatcyclemia-totalsupply
The naming should be in alignment with the contract variable/map/function names, types directory, and handlers so it's easily associated. City data can be filtered by the city abbreviation when fetching a full list of keys.
Data points like mia-activationblock can be queried if not found per city, then stored indefinitely and used to serve the response.
Data points like mia-totalsupply could take advantage of expiring keys to make sure the data gets fetched again in regular intervals.
Data could be updated as it's fetched, or a cron job could be run by the worker to make updates on regular intervals, or both.
Additional general KV data points could be used as well, such as saving the last seen block height and using that to determine if a new value needs to be fetched.