Akamai Integration
GraphQL Caching with AAM
AAM adds a fully programmable GraphQL caching layer when deployed on Akamai Connected Cloud, implemented as an inbound policy that handles query normalization, variable canonicalization, fragment handling, and deep nesting with no changes to the upstream service.
Akamai default vs AAM
Akamai's built-in GraphQL caching skips or fragments the cache in several common cases. AAM's programmable caching layer handles all of them.
Live Demo
Each test makes two real requests to the AAM gateway. Click Run Test ↗ to see cache behavior live. Timing and x-cache headers come directly from the deployed gateway.
Cache TTL is 60 seconds. If request 1 shows HIT, the cache is warm from a previous run. Wait 60s and run again to see the full MISS to HIT cycle.
Basic GraphQL Caching
Baseline behavior. The same query sent twice. The first request goes to the origin (MISS) and the second is served from AAM's edge cache (HIT).
Deep Query Nesting (21+ Levels)
A 21-level nested query against a recursive mock backend that supports arbitrary depth. Akamai's default cap is 20 levels; exceeding it falls back to uncached plain POST. AAM has no depth limit.
No 4,096-Byte Query Size Limit
A ~4,800-byte query with 60 aliased fields. Akamai bypasses GraphQL analysis and caching above its default size limit. AAM parses and caches it regardless of size.
Query Normalization
The same query in compact formatting (request 1) vs verbose whitespace (request 2). AAM normalizes via AST parse + print before hashing. Both resolve to the same key.
Fragment Normalization
The same fragment-based query in compact (request 1) vs verbose (request 2) whitespace. AAM's AST round-trip normalizes fragment spreads identically regardless of formatting.
Variable Key Canonicalization (configurable)
The same variables passed with keys in different order. JSON key ordering is not guaranteed. AAM sorts variable keys recursively before hashing so both resolve to the same cache entry.
Test It Yourself
Send your own GraphQL query to the AAM gateway and see whether it hits the cache. Use a preset or write your own.
Quick start
How It Works
The caching layer is a single TypeScript inbound policy on every GraphQL route. It runs on AAM's edge runtime and works identically across all deployment models: Managed Edge (Cloudflare), Managed Dedicated (any cloud), and Self-Hosted Kubernetes.
- 1
Parse
Incoming query parsed with the graphql npm package. No size limit.
- 2
Gate on operation type
Mutations and subscriptions pass through uncached.
- 3
Normalize
parse() → print() canonicalizes whitespace, field order, and fragments.
- 4
Canonicalize variables
Recursive key sort so {b,a} and {a,b} produce the same hash.
- 5
SHA-256 cache key
normalizedQuery + canonicalVariables hashed via Web Crypto API.
- 6
Cache lookup / store
HIT returns immediately; MISS stores the response via addResponseSendingHook.
Ready to deploy GraphQL caching on AAM?
Talk to the AAM team about adding a programmable caching layer to your Akamai-fronted GraphQL APIs.