Caching And Redis

Configure response caching, stale-while-revalidate, Redis backend selection, and invalidation.

Response cache

YAML

caching:
  disable: false
  ttl: 3600
  fresh_ttl: 300
  exclude_tables:
    - audit_logs

ttl is the hard expiry. fresh_ttl controls stale-while-revalidate behavior. Mutations invalidate cache entries through tracked table and primary-key references.

Verified by TestCacheKeyBuilder_DatabaseIsolation core/cache_key_test.go:337

Verified by TestRedisCache_PerEntryTTLsCapButDoNotExtendDefaults serv/cache_redis_test.go:180

Cache keys include query/APQ identity, variables, role, user identity, and database scope. This is important in multi-database deployments: the same GraphQL operation against two source databases must not share a response entry.

Verified by TestCacheKeyBuilder_RoleIsolation core/cache_key_test.go:88

Verified by TestBuildCacheKey_DatabaseScope core/cache_key_test.go:350

Redis backend

YAML

redis:
  url: ${REDIS_URL}

Redis is useful when multiple GraphJin instances need shared cache state.

Remote fragments and filesystems

Remote fragments, OpenAPI calls, and filesystem tables add source-specific cache refs. Filesystem list queries include prefix refs so a write to users/1/avatar.png can invalidate both the exact key and affected list prefixes.

Verified by TestRemoteFragmentRefs_FilesystemListIncludesRootPrefix core/cache_response_test.go:61

Verified by TestRedisCache_FilterExcludedSourceScopedRefs serv/cache_redis_test.go:210