You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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-activationblock
mia-miningstatsatblock
mia-stackingstatsatcycle
mia-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.
The text was updated successfully, but these errors were encountered:
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-activationblock
mia-miningstatsatblock
mia-stackingstatsatcycle
mia-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.
The text was updated successfully, but these errors were encountered: