Difference from other Ruby Redis clients

[Alexey2257]

Hi! Since Ruby core supports fiber scheduler, I suppose using a different Ruby Redis client that uses TCP will work with Async in the same way. I mean, when called from an Async block, it will be detected as I/O and will pass control, right? So, I wonder, are there explicit reasons to use async-redis with Async, except for the built-in use of async-pool, which I find very convenient?

[ioquatix]

I personally worked hard on ensuring the interface is more consistent and easier to use. This is especially true for our support of pipelines, transactions and subscriptions. As you mentioned, our connection pooling is easier to user than the alternatives.

From Async 2+, you are correct, other implementations, that use native Ruby IO, will correctly be handled by the event loop.

[spajic]

Really appreciate all your hard work and contribution to making Ruby async, @ioquatix !

I kinda double on this question cause from the first glance it wasn't obvious what is the difference from other Redis clients.
One guess is that it must be used to be able to work with socketry/async v1 and maybe it is not relevant since v2

So thanks for your explanation!

[ioquatix]

One aspect of Redis that I did not fully appreciate until recently, was how convenient and useful it was to run transactional LUA code on the server. There are many operations that can't be done safely with the normal "RESP2" interface. Instead, we should execute sequential code on the server. Check out https://github.com/socketry/async-job/blob/main/lib/async/job/backend/redis/processing_queue.rb and the other files in that directory for examples.

[Alexey2257]

Thank you for clarification!