rmosolgo / rmosolgo/graphql-ruby
Cache complexity analyzer in-memory/redis
Nobody has claimed this yet.
- Dominant language
- Ruby
- Stars
- 5.4k
- Forks
- 1.4k
- Avg merge
- 23h 19m
- Merged PRs (30d)
- 28
Description
Is your feature request related to a problem? Please describe.
After the optimization in https://github.com/rmosolgo/graphql-ruby/pull/5631,
our GraphQL/analyze dropped from ~806ms to ~176ms. However, 176ms is still
significant for a hot path since the complexity analyzer runs on every request,
even when the same query has been analyzed before.
Describe the solution you'd like
I would like a way to cache the complexity analysis result across requests —
either in-process (Ruby Hash/LRU, sub-microsecond) or in a shared store like
Redis (~1ms). The gem itself does not need to know how to cache; that
responsibility can stay with the application. What the gem needs to provide is
a stable fingerprint for the incoming query so the application can use it
as a cache key.
The challenge is determining what the fingerprint should cover. The complexity
of a query depends on its structure and on certain variables — most notably
pagination arguments (e.g. first, last) — so those must be included in the
fingerprint.
Describe alternatives you've considered
Keying the cache on the full query string + all variables is too conservative:
two calls with the same query structure but different id arguments would
always miss the cache even though their complexity is identical.
Keying on the query string alone (ignoring all variables) is too aggressive:
it would treat first: 10 and first: 1000 as the same, producing incorrect
complexity results.
The right fingerprint is the query structure (document or normalized AST)
combined with only the variables that influence complexity, such as pagination
arguments.
Additional context
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the complexity analyzer and the optimization in pull request 5631, then trace the GraphQL/analyze path. Define and validate a stable fingerprint that includes query structure and complexity-relevant variables such as pagination arguments, while allowing equivalent queries with unrelated variable changes to share a cache key.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- graphql, ruby
- Domain
- backend-api-design, performance
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100