redis-rb.md

Plan for redis-rb 5.0

A large part of redis-rb maintenance cost comes from having to implement each command Redis add. A year after Redis 6.2 release, we're still missing a large part of the newly added commands, and tengentially commands added by Redis modules are hard to use.

This comes down to the RESP2 protocol that requires to know how to parse each command output.

However Redis 6.0 introduced the RESP3 protocol, which is properly typed allowing clients to not know anything about the commands they are sending, which means a drastically simpler and smaller implementation that don't need keeping up with commands added upstream.

So I'd like to split redis-rb in multiple gems (probably kept in the same git repository)

redis-client gem

What I'd like to do is to start a new simpler redis-client gem, that only support Redis 6.0+ and pretty much only offer the following API:

redis = Redis::Client.new(...)

# sending command
redis.call('SMEMBERS', 'mykey', ...)

# pipelining
redis.pipeline do |pipe|
  pipe.call(...)
end

We may also need some API for dealing with subscriptions commands, but that's about it unless I'm missing something.

This simple client would:

• Not support redis-cluster, it should be implemented as another gem, the vast majority of people don't need it.
• No longer wrap calls with a mutex, it's a mis-feature of redis-rb, to share a client between theads use a thread pool.

Users should be encouraged to use redis-client directly.

I explored this avenue back in 2019.

redis-cluster-client gem

Clustering support adds lots of complexity, so I think it should be shipped separately for people that need it.

It should however be API compatible.

One difficulty with clustering is that the client must be able to extract the parts of the command that are keys.

Right now this is handled with lots of ad hoc code for each command, but we should instead load the list of command signatures from the redis server with COMMAND and extract the keys that way.

With the above redis-cluster-client should be able to be a drop-in replacement for redis-client

redis-rb 5.0

redis-rb should then be refactored to be a thin wrapper around redis-client allowing to keep backward compatibility for the most part. Users would still be encouraged to migrate to redis-client even though there is not plan to sunset the redis gem.

Since we wouldn't have to know about return types, we could also explore generating the methods from the COMMANDS output, as to simplify keeping up with Redis.

Timeline

I don't have a specific timeline yet.

Redis 6.0 will soon be the oldest supported version. I also see that Sidekiq plans to only support Redis 6+ soon, so 2022 is likely the good time for this to happen.