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

Allow disabling introspection responses going to cache #4861

Open
smyrick opened this issue Mar 26, 2024 · 2 comments
Open

Allow disabling introspection responses going to cache #4861

smyrick opened this issue Mar 26, 2024 · 2 comments

Comments

@smyrick
Copy link
Member

smyrick commented Mar 26, 2024

Is your feature request related to a problem? Please describe.
Currently, introspection queries and their response data is saved to the cache, which also populated in Redis.

self.cache.insert(query, response.clone()).await;

If I have an extremely large schema and I have clients making slightly different introspection queries this can start sending lots of data to my Redis instance and eating up performance, bandwith, and storage

Describe the solution you'd like
Allow configuring or disabling if introspection responses are cached or not

Enabled cache

supergraph:
  introspection:
    enabled: true
    cache: 
      in_memory:
        limit: 1
      redis:
        urls: [ "redis://localhost:6379" ]

Disabled cache

supergraph:
  introspection:
    enabled: true
    cache: false # Not sure what is better here. I think default should be cache on, so how do we turn it off?
    cache: 
      in_memory:
        enabled: false
      redis:
        enabled: false

Describe alternatives you've considered
There is no control over this today. I need to enforce that introspection is all the same or I can disable it entirely

supergraph:
  introspection: false

Additional context
Maybe as part of the issue #4608 we can add more features

OR

We could lock down introspection to only 1 predefined operation: #4871

@SimonSapin
Copy link
Contributor

Introspection is not computationally expensive. I wonder if we’d be better off not caching it at all.

@abernix
Copy link
Member

abernix commented Apr 19, 2024

We may have only cached it previously because it was going through the router-bridge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants