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 :)