opa
opa copied to clipboard
Possible to cache graphql.parse() results?
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
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?
@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.
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.
This issue has been automatically marked as inactive because it has not had any activity in the last 30 days.
This issue has been automatically marked as inactive because it has not had any activity in the last 30 days.
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 :-(
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.