Skip to content
|
Plugin Hub
github-edit-pageEdit this page
report-issueReport an issue
header icon

GraphQL Proxy Caching Advanced

By Kong Inc.
You are browsing unreleased documentation.

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.

Strategies

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:

  • memory: A 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.

Cache Key

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)

Where headers contains the headers defined in vary_headers, which defaults to none.

Kong will return the cache key associated with a given request as the X-Cache-Key response header.

Cache Status

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 cache_ttl threshold.
  • Bypass: The request could not be satisfied from cache based on plugin configuration.

Get started with the GraphQL Proxy Cache Advanced plugin