The DB implementation need to implement caching. Retrieving a Twin X should be cached for a certain amount of minute (say 20 minutes) after that the twin object must be retrieved again from substrate in case the twin IP was updated.
Suggest implementation for caching:
rmb works always with redis. Hence it can be a good idea to use that to store twin objects, with proper TTL
for example:
let db = TwinDB::new(substrate).cache(redis);
This way the twin db can work normally without caching, or if cache is set (not None) it will start to use redis for caching. redis in this case should be a redis pool object suggest to use https://docs.rs/bb8-redis/latest/bb8_redis/
Hint: the cache can also be a trait so the twin-db can be work against any object that implements the cache trait, later a redis implementation can be done that actually uses the pool. Hence the twin db implementation can be completely abstrat.
This is an abstract layer on top of substrate. The point of this DB is to retrieve Twin information object (this include its public key, and IP).
The DB implementation need to implement caching. Retrieving a Twin
Xshould be cached for a certain amount of minute (say 20 minutes) after that the twin object must be retrieved again from substrate in case the twin IP was updated.Suggest implementation for caching: rmb works always with redis. Hence it can be a good idea to use that to store twin objects, with proper TTL
for example:
This way the twin db can work normally without caching, or if cache is set (not None) it will start to use redis for caching. redis in this case should be a
redis pool objectsuggest to use https://docs.rs/bb8-redis/latest/bb8_redis/Hint: the cache can also be a trait so the twin-db can be work against any object that implements the cache trait, later a redis implementation can be done that actually uses the pool. Hence the twin db implementation can be completely abstrat.