Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RESTDataSource cache: Support for redis sentinel #1725

Closed
eberhara opened this issue Sep 25, 2018 · 5 comments
Closed

RESTDataSource cache: Support for redis sentinel #1725

eberhara opened this issue Sep 25, 2018 · 5 comments
Labels
⛲️ feature New addition or enhancement to existing solutions

Comments

@eberhara
Copy link
Contributor

eberhara commented Sep 25, 2018

Hey guys,
As far as I know, apollo-server supports caching on redis, in memory or memcached.
apollo-server-cache-redis uses npm's redismodule in order to create a redis client.

The redis module does not currently support redis sentinel, as per some issues like redis/node-redis#302

I am opening this issue so we can discuss how to support redis sentinels on RESTDataSource caching.

So, should we create a new package like apollo-server-cache-redis-sentinel? Or, should we support sentinels on the existing apollo-server-cache-redis? Or, should the client using ApolloServer be responsible for creating a new KeyValueCache implementation that supports sentinels?

Thanks in advance!

@ghost ghost added ⛲️ feature New addition or enhancement to existing solutions 📚 good-first-issue Issues that are more approachable for first-time contributors. labels Sep 25, 2018
@sbrichardson
Copy link
Contributor

The easiest thing to do, if you need the feature now, would be to extend the class, overwriting the constructor of apollo-server-cache-redis, or just create a new package that does it directly etc.

You would just need to duplicate some code from the exisiting redis-cache package there.

I did this to use Google's Redis API with their client.

@eberhara
Copy link
Contributor Author

Good idea.

I will probably extend the class on my server, but do you think it would be good if we had an “apollo-cache-redis-sentinel” as part of apollo packages?

@sbrichardson
Copy link
Contributor

sbrichardson commented Sep 27, 2018

It's hard to say. I think if it was consistently implemented, other packages would be convenient. The current redis package is pretty basic and hard coded (not a bad thing).

It's a simple package and each implementation could be slightly different. For example, I use hashes hget vs the current mget.

With the current design, it would create a lot of duplicate code since everything in the constructor has to be copied, just to change the underlying client.

It could take an option with an already instantiated client like below, but then other methods may break, such as the close() or how they are promisfying methods, it would need to be fully compatible to work.

I think the original intent was to have an easy enough API for KeyValueCache that you just create a new cache package as needed.

export class RedisCache implements KeyValueCache {
   constructor(options: Redis.ClientOpts) {

    // Potentially could add an option to pass a client

    const { client: userClient, ...opts } = options

    const client = userClient || Redis.createClient(opts);
 
    // promisify client calls for convenience
    client.mget = promisify(client.mget).bind(client);
    client.set = promisify(client.set).bind(client);
    client.flushdb = promisify(client.flushdb).bind(client);
    client.quit = promisify(client.quit).bind(client);

    this.client = client;

    this.loader = new DataLoader(keys => this.client.mget(keys), {
      cache: false,
    });
  }

@abernix abernix removed the 📚 good-first-issue Issues that are more approachable for first-time contributors. label Sep 27, 2018
@eberhara
Copy link
Contributor Author

eberhara commented Oct 4, 2018

Just created a PR #1770 with an implementation for that. Maybe we can discuss on top of that.

@abernix
Copy link
Member

abernix commented Jul 3, 2019

Happy to re-open if this isn't resolved with #1770, but I hope that did the trick! :)

@abernix abernix closed this as completed Jul 3, 2019
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 21, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
⛲️ feature New addition or enhancement to existing solutions
Projects
None yet
Development

No branches or pull requests

3 participants