Include a default redis client

[nfriedly]

Description

I think we should include a default redis client, and accept a new option for the connection details that is passed directly to the redis client.

I think node-redis and ioredis are the two most popular ones. node-redis has more github stars while ioredis has more npm downloads. I'm leaning a bit towards ioredis since it has a smaller file size, although node-redis has the advantage of only accepting 0 or 1 arguments to it's constructor, whereas ioredis accepts 0-3. (We could accept an array for the 2+ arg versions.)

We should still keep the sendCommand option around for backwards compatibility and advanced usage. It should probably throw an error if both sendCommand and our new option are set at the same time.

Why

• Simplify usage
• Enable clustering support - RedisStore: args.length: Cannot read properties of undefined (reading length). #207

Alternatives

Not changing anything

[gamemaker1]

I'm on the fence for this one; don't really see a need to add this option. We can fix #202 by explaining the sendCommand function better in the documentation.

However, if we do implement this, I think we should go with ioredis.

[moohbr]

Apologies for the delayed response (university problems), but after spending some time troubleshooting...

The developers can't simply replicate the solution from rate-limit-mongo (#202) because in this solution the team tailored a MongoDB client specifically for this purpose. Therefore, if we aim to achieve similar functionality, we need to rely on a single Redis client, this might deviate from the original approach.

So, I believe that have two sides:

1st side:

• Add the documentation in the method sendCommand explain that may override.
  

• Add a default client like ioredis .

2nd side (and I prefer it):

• Deprecate the method sendCommand and use, if possible, the pure default Redis client (or yours prefers) for it.

I believe that using the default Redis client can be more transparent for users, avoiding adding a lot of dependencies to their projects.

[nfriedly]

No worries.

The trouble is that I'd like to avoid a breaking change unless it's really necessary. I also think there are some more advanced use-cases where being able to provide a custom sendCommand is still valuable. So I don't really want to get rid of that option. I just want to make basic usage easier.

I'm ok with either node-redis or ioredis as the built-in client, because the folks who care will still have the option of using their own via sendCommand.

Improving the documentation is always good :)

[avifenesh]

Please consider using one of Valkey clients, which is open source, and not a client which is under not OSS org.

I'm a valkey-glide maintainer, and obviously would like to see glide as the primary client. But anyway, at least something that will let folks enjoy the growth and development of valkey with a client that supports the new features and keeps being compatible.

Soon, most users will use valkey.
Redis is not delivered anymore in the package managers of most Linux distros, the big cloud providers are supporting valkey, and stopped delivering new versions of Redis, while dropping the price on Valkey, and libraries are moving main support to valkey.
Along with that, Valkey keeps growing and delivering significant features, like AZ affinity, the new hash table design, the performance improvement, TTL on hash keys is on the way, and many more, and users will want to enjoy it.
Meanwhile, in Redis, the special features going to the pro versions, even clients started support features for redis only.

So I think it will benefit users in the future if the built-in client that comes with the library is future safe, and it gets better.