Migrate to official node-redis

[nodegin]

Is your feature request related to a problem? Please describe.

ioredis is being non-actively maintained for a while, it seems will be deprecated soon.
redis/node-redis#2658 (comment)

Describe the solution you'd like
Migrate to https://github.com/redis/node-redis

Describe alternatives you've considered
n/a

Additional context
n/a

[manast]

Yeah, this is a quite a sad situation, it almost seems like Redislabs is being run by a chicken without head... most frustrating is the lack of communication with the community, leaving everybody wondering what is going on.

But from BullMQ's point of view, there is not a single issue with IORedis that we are aware of, and would such an issue arise we will fork IORedis and fix it for us. The only feature that would be relevant in terms of performance would be to have support for RESPv3 but neither IORedis nor node-redis supports it.

The APIs of IORedis and node-redis are different enough to make the work of supporting node-redis non-trivial, and there is no guarantee it will be better maintained either, in fact the number of commits seems to be quite low too...

If somebody really wants to use node-redis, one possibility would be to create a wrapper on top of node-redis that implements the IORedis specific APIs that are used by BullMQ... but I do not think this is worthy right now.

[manast]

Btw, it could be that some security advisory arises in IORedis that forces us to fork it even though there are no other issues, but lets give Redislabs a chance to make things right.

[codeagencybe]

What about moving to keydb or dragonfly? Both are decent drop-in replacements for redis and both open source.
in terms of performance, they both claim to be much faster than redis too.
Sounds like multiple wins then?

[manast]

Dragonfly is supported, as it is 100% compatible with Redis (https://bullmq.io/news/101023/dragonfly-compatibility/). KeyDB did not properly work with BullMQ last time I tested and probably does still not work but I am not sure.

In any case this discussion is about the NodeJS client library and less about the change in Redis license. I do not think the new Redis license affects regular users, but instead hosting providers which will now need to get a commercial license agreement from Redis in order to provide the newer versions. If I have to guess, these changes will just encourage new forks and competition to fill the need for a robust in-memory database, so not bad news for current Redis users in the long run.

[ivan-kleshnin]

Describe the solution you'd like
Migrate to https://github.com/redis/node-redis

It's not well supported either 😞
Look at the number of issues, at the absence of comments there, hanging PRs, look at the release history.

[manast]

@ivan-kleshnin yes, thats why I am more confident to continue using just IORedis, as over the years @luin has fixed the issues that affected BullMQ and AFAIK there are no known issues that affect us... just keeping IORedis up-to-date regarding security updates should not be a big effort, but obviously some maintainer must merge the PRs and make the releases otherwise nothing will happen.

[jamesarosen]

But from BullMQ's point of view, there is not a single issue with IORedis that we are aware of, and would such an issue arise we will fork IORedis and fix it for us.

That's true, but there are plenty of bugs in ioredis that don't directly affect BullMQ. If a job uses Redis for something else (like geodist calculations), it likely needs to load two redis clients. That's a waste of developer time, CPU time, and CO2.