open-policy-agent / opa

Open Policy Agent (OPA) is an open source, general-purpose policy engine.
https://www.openpolicyagent.org
Apache License 2.0
9.37k stars 1.3k forks source link

Possible to cache graphql.parse() results? #5377

Open edulop91 opened 1 year ago

edulop91 commented 1 year ago

Short description

I am wondering if there is an easy way to cache the graphql schema AST that is generated by graphql.parse function call. I have been working on integrating OPA for our graphql layer and, unfortunately, am running into performance issues due how long it takes to generate the AST from a raw query.

Our graphQL schema does not change between each authorization decisions and therefore it makes sense to generate thes chema AST once and re-use it for each authorization query.

I am running OPA embedded into Go mode. This is running locally from my laptop.

Steps To Reproduce

Nothing really interesting here. Rego looks like:

package graphql

import future.keywords

query_ast := graphql.parse(input.query, input.schema)[0]

The only difference is having farily large input.query and input.schema.

Expected behavior

I would like to find a way to cache my graphql schema AST between authorization decisions.

Additional context

srenatus commented 1 year ago

I think it should be possible to do this transparently. I.e. any call to graphql.parse(..) would check if the schema was already parsed, and retrieve that from the inter-query cache.

🤔 I wonder if this should be a feature to opt-in to, or if we need to worry about the cache growing too large... @philipaconrad What do you think?

philipaconrad commented 1 year ago

@srenatus I agree that we could probably borrow the inter-query cache system for this, but it easily could cause a memory usage spike for folks with many unique GraphQL schemas that get cached.

srenatus commented 1 year ago

Mentioned OOB -- maybe some sort of LRU cache could help here. If we cache 10 schemas, we'd probably solve the problem for most users, while not blowing up the memory usage for those special cases where many unique schemas are parsed. For those special cases, the situation would get neither better nor worse from having an LRU.

stale[bot] commented 1 year ago

This issue has been automatically marked as inactive because it has not had any activity in the last 30 days.

stale[bot] commented 1 year ago

This issue has been automatically marked as inactive because it has not had any activity in the last 30 days.

adepretis commented 3 months ago

I am hitting the same issue. A schema with about 2000 lines takes about 2-3 seconds to parse - for every request. Without some kind of cache this is not feasible :-(

stale[bot] commented 2 months ago

This issue has been automatically marked as inactive because it has not had any activity in the last 30 days. Although currently inactive, the issue could still be considered and actively worked on in the future. More details about the use-case this issue attempts to address, the value provided by completing it or possible solutions to resolve it would help to prioritize the issue.