Did you know that you can try this plugin without talking to anyone for just $5/month with Kong Konnect? Get started in under 5 minutes.
Looking for the plugin's configuration parameters? You can find them in the GraphQL Proxy Caching Advanced configuration reference doc.
This plugin provides a reverse GraphQL proxy cache implementation for Kong Gateway.
It caches response entities based on configuration. It can cache by GraphQL query or Vary headers.
Cache entities are stored for a configurable period of time, after which subsequent requests to the
same resource will re-fetch and re-store the resource.
Cache entities can also be forcefully purged via the Admin API prior to their expiration time.
Kong also provides a GraphQL Rate Limiting Advanced plugin.
The GraphQL Proxy Caching Advanced Plugin is designed to support storing GraphQL proxy cache data in different backend formats.
Currently the following strategies are provided:
lua_shared_dict. Note that the default dictionary,
kong_db_cache, is also used by other plugins and
elements of Kong to store unrelated database cache entities. Using this dictionary is an easy way to bootstrap the
graphql-proxy-cache-advanced plugin, but it is not recommended for large-scale installations as significant usage will put pressure
on other facets of Kong’s database caching operations. It is recommended to define a separate
lua_shared_dict via a
custom Nginx template at this time.
Kong keys each cache elements based on the GraphQL query that is being send
in the HTTP request body. Internally, cache keys are represented as a
hexadecimal-encoded MD5 sum of the concatenation of the constituent parts.
key = md5(UUID | headers | body)
headers contains the headers defined in
vary_headers, which defaults to
Kong will return the cache key associated with a given request as the
X-Cache-Key response header.
Kong identifies the status of the request’s proxy cache behavior via the
X-Cache-Status header. There are several
possible values for this header:
Miss: The request could be satisfied in cache, but an entry for the resource was not found in cache, and the request
was proxied upstream.
Hit: The request was satisfied and served from cache.
Refresh: The resource was found in cache, but could not satisfy the request, due to
Cache-Control behaviors or
reaching its hard-coded
Bypass: The request could not be satisfied from cache based on plugin configuration.
Get started with the GraphQL Proxy Cache Advanced plugin