Support for Redis Sentinel and Cluster about graphql-redis-subscriptions

[davidyaha]

I understand completely the reason and also I would have done it this way in order to avoid managing the clients connections on this package, but I would like to have a default client being created for you as this is two connections.

My plan would be to create optional fields to provide the publish and subscribe connection by the user, create optional dependency on redisio and if the user has not provided subscribe or publish clients then I will create a default one (check that the dependency is satisfied).
If the user has not supplied the clients and the dependency is missing, throw an error that directs the user.

I would like to have this logic in order to allow users fast prototyping as subscriptions could be a bit of a hassle to setup at the moment.

What do you think of this plan?

[davidyaha]

Adding to the discussion the current node-redis roadmap redis/node-redis#1040

[davidyaha]

BTW, @amitshlo Will gladly merge a PR.

[amitshlo]

Like you saw, I started working on it.
After we saw the createClient function is deprecated I started to wonder how I should mock the Redis client for the tests.
After some research and a few trys to implement a mock for 'new Redis({...})' I saw (and read) that the best practice is to send a client (created by the user) in the constructor.

Any thoughts (and, what do you think about the fact that people will need 2 clients to send)?

[amitshlo]

Sounds good, actually it's also done in many packages of this kind (session stores for example).
But you have to forgive me, I'm not sure I totally understand what "optional dependency" mean. The package will have to have 'ioredis' as a dependency.

[davidyaha]

I mean npm's optional https://docs.npmjs.com/files/package.json#optionaldependencies
Partly unknown feature but very helpful for these kind of things.
What you do is adding ioredis as optional dep and also as dev dep and then use require in a try-catch block.

[amitshlo]

OK, very cool!

[julienvincent]

In my opinion both option 1 and 2 should be implemented at some point.

Being able to pass in subscriber and publisher client would mean the library consumer has direct and explicit control of the redis streams.

Regardless of whether option 1 gets implemented though I do think that ioredis would be a better default than node_redis at this point due to the out-of-the-box sentinel support.

[julienvincent]

@amitshlo any status on the PR you are working on? I would also happily contribute to implementing one of the above options.

[amitshlo]

@julienvincent it's actually almost complete, there's one comment @davidyaha gave me about tests that I don't understand, so I'm waiting for him to reply...

#78

[julienvincent]

@amitshlo I didn't see you had already submitted, looks good. I'm very keen to see it #78 get merged