Cache complexity analyzer in-memory/redis
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- graphql, ruby
- Domain
- backend-api-design, performance
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.
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
- Dominant language
- Ruby
- Stars
- 5.4k
- Forks
- 1.4k
- Avg merge
- 23h 19m
- Merged PRs (30d)
- 28
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.
More from rmosolgo/graphql-ruby
-
Difficulty 4/5 3-5 days Newbie friendliness 52/100
rmosolgo/graphql-ruby#5707 · 10 comments ·
-
Difficulty 3/5 1-2 days Newbie friendliness 30/100
rmosolgo/graphql-ruby#5655 · 4 comments ·
-
Migrate to RDoc Open
Difficulty 5/5 Over a week Newbie friendliness 30/100
rmosolgo/graphql-ruby#5576 · 2 comments ·
-
Difficulty 3/5 1-2 days Newbie friendliness 48/100
rmosolgo/graphql-ruby#5572 · 5 comments ·
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
rmosolgo/graphql-ruby#5535 · 2 comments ·
All issues in rmosolgo/graphql-ruby
Similar issues
-
user-reported
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Kong/developer.konghq.com#7316 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
TheOdinProject/curriculum#31408 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
notch8/utk_knapsack#148 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 78/100
Homebrew/homebrew-cask#288729 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100