rmosolgo / rmosolgo/graphql-ruby

Cache complexity analyzer in-memory/redis

Open
#5,632 4 comments 0 reactions 0 assignees View on GitHub

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

https://github.com/rmosolgo/graphql-ruby/pull/5631

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.