search

aembke / fred.rs

An async Redis client for Rust.
Apache License 2.0
382 stars 61 forks source link

[Feature request] Support for client-side caching #99

Closed kika closed 1 year ago

kika commented 1 year ago

This will require supporting commands CLIENT TRACKING and CLIENT CACHING plus notification channel for RESP2 and RESP3. I can probably take a stab at a PR if this is considered a good idea, but I'll need some guidance because inner workings of the crate a very clearly written but not documented much.

The first guidance question is the design of the OPTIN case: should I implement CLIENT CACHING as a high-level command/method and just issue it before every read operation I want to be notified about? Or we'd better have some abstraction built in that allows to mark the commands or keys we're interested in and automatically issue CLIENT CACHING before each command? Maybe RedisConfig option?

aembke commented 1 year ago

Hey @kika, apologies on the delay getting back to you here.

This one is interesting. I had an attempt at the interface for this on a local branch from a while ago, and I just updated it and pushed it to this branch. It implements a basic interface that exposes the CLIENT TRACKING, CLIENT GETREDIR, CLIENT TRACKINGINFO, etc commands directly, as well as a higher level interface via a new TrackingInterface trait that works with all server deployment modes.

The implementation is still missing but I sketched out the two interface examples here: https://github.com/aembke/fred.rs/blob/feat/client-tracking/examples/client_tracking.rs.

Let me know if you have any thoughts on the interface or if that works for your use case.

aembke commented 1 year ago

Added in https://github.com/aembke/fred.rs/pull/117