Cache Providers

[quinchs]

Summary

DNET Labs should expose ways for developers to use other means of caching within their bot, the goal of this is to help with bigger bots and reduce memory use within the library.

Things to do:

• Add a way for developers to create a ICacheProvider and use it within their client
• Make entities serializable for caching "offshore", needs to be fast to serialize and deserialize
• Create a default cache provider.
• Improve on the overall memory usage of the dnet labs library

Feel free to use this issue as a discussion for CacheProviders, all feedback is welcome

[quinchs]

One idea for serializing is having each entity thats cached implement a model serializer that directly converts it to a byte array, this way communication for offshore caches can be done thru network based means. This also has the benifactor of being small in size.

[dmcbride]

I've been searching for ICacheProvider, I'm not sure where this is from.

The main problem I'm looking to solve in my bot right now is the speed of the user downloads. In theory, caching could help here, but I wonder how you would deal with issues of changes to whatever you're caching happening during bot restarts?

Whether the offshore data is in sql or nosql, I'm curious as to how you're thinking to approach data relationships? For example, as users are added or removed from a guild, you don't really want a master list of all users. When finding all users with a given role, you don't really want to iterate through every user looking for them. Ideally, you would ask the cache provider for that, and let the implementation there figure out how to handle it. I regularly use mongo, redis and mysql, and the approach I'd take in each of these scenarios would be significantly different. However, if you just pass a byte-array, a binary blob, to the cache provider, presumably with a key, the cache provider will be pretty limited in how it can improve performance here, so I'm assuming you're thinking of a bit more than that?

Side note - when I'm caching stuff in redis, I've taken to using protobuf for the binary serialisation. That may be something to consider, but the reality is that you can let someone else provide a ProtobufCacheProvider that handles that.

[quinchs]

The main issue is having an efficient and fast was of serializing and deserializing strong typed entities which contain references to other strong typed entities. The reason I'm starting with byte arrays is because it covers alot of potential applications of a cache provider.

I've had a few discussions with some large scale developers and we came up with having different types of cache providers: a smart cache provider and a "dumb" cache provider. The smart one would support linq and other forms of querying while the dumb one doesnt. The main issue is the querying - since the data is a byte array you would have to deserialize it to query the properties.

Maybe it would be simpler to just expose json data and allow developers to send this any way they want, this would also make in language querying a bit easier.

[dmcbride]

I wouldn't even suggest exposing json data. Just expose the data model you want cached, and let the developer convert it to binary, json, protobuf, whatever, as they need. As long as your interface indicates the types of activities you need to allow the developer to figure out the optimisation strategy, it should be fine. For example, getting all the users based on guild ID, or all the users based on role ID and guild ID, updating a user, etc.

Third-party packages could provide common strategies, such as redis or mongo or sql or in-memory or whatever.

[quinchs]

Alright. Some other concerns that may come up is sharding, shards should be able to fetch/store their data per shard - not collectively amongst them. There's some use cases to do this as well as query all shards data. To resolve this I could attach a shard id to all models when sharding to query against.