Modern software design relies heavily on distributed systems architecture, requiring all APIs to be robust and secure. GraphQL is no exception and is commonly served over HTTP, subjecting it to the same management concerns as any REST-based API. In fact, GraphQL’s dynamic client querying capabilities may lead to more complex and potent attack surfaces than traditional REST-based APIs.
The GraphQL [official documentation](https://graphql.org/learn/serving-over-http/#web-request-pipeline)official documentation makes the following recommendation:
*GraphQL should be placed after all authentication middleware, so that you have access to the same session and user information you would in your HTTP endpoint handlers.*
In this post, we will evaluate proxying GraphQL endpoints with Kong Gateway, which provides exceptional capabilities for protecting and governing multiple API technologies.
Our previous post looked at building an experience API using GraphQL for our fictitious airline, KongAir. Today, we’ll look at managing and protecting that API with Kong Gateway on Kong Konnect using [APIOps](https://konghq.com/blog/product-releases/deck-1-24)APIOps.
API gateways are prominently situated at the edge of your infrastructure and negotiate traffic between front-end clients and back-end services.
Modern API gateways must provide some key functionalities, including:
Critically these functions abstract these requirements away from your service developers allowing them to focus on business development needs.
Kong Gateway provides all of the above capabilities and more, including native GraphQL support for caching and rate limiting.
In the modern distributed architecture, performance optimization and rapid response times are pivotal. Proxy caching is a common technique for improving response times and reducing upstream service loads. With [Kong GraphQL Proxy Caching Advanced](https://docs.konghq.com/hub/kong-inc/graphql-proxy-cache-advanced/)Kong GraphQL Proxy Caching Advanced plugin, users get a simple mechanism to deploy reverse GraphQL proxy cache.
The caching plugin keys each cached element based on the GraphQL query that has been sent in the HTTP request body and, optionally, a configurable set of request headers. The caching plugin supports a configurable time to live (TTL) for admins to control the lifetime of a cached response.
Resource protection is critical to ensuring robust and available systems. Rate Limiting is commonly used to mitigate denial-of-service attacks, helping to maintain system health and stability. GraphQL services are no different, and the [Kong GraphQL Rate Limiting Advanced](https://docs.konghq.com/hub/kong-inc/graphql-rate-limiting-advanced/)Kong GraphQL Rate Limiting Advanced plugin provides a GraphQL-aware algorithm for calculating request cost.
GraphQL services typically respond to queries from a single HTTP path, and due to the nature of dynamic client GraphQL queries, normal HTTP path-based rate limiting is not sufficient. The same HTTP request to the same URL with the same method can vary greatly in cost depending on the semantics of the GraphQL operation in the body. See the [documentation](https://docs.konghq.com/hub/kong-inc/graphql-rate-limiting-advanced/api/)documentation for more details on how request costs are calculated.
In the [previous post](https://konghq.com/blog/engineering/building-dynamic-aggregate-apis-with-graphql)previous post, we introduced the KongAir *Experience API* built with GraphQL. Today, we are going to look at deploying GraphQL plugins on Kong Gateway in front of our GraphQL service, protecting it and improving overall system performance.
KongAir follows an automated [APIOps process using Kong’s decK tooling](https://konghq.com/blog/product-releases/deck-1-24)APIOps process using Kong’s decK tooling to deploy APIs onto Kong Konnect, a [complete SaaS API management platform](https://konghq.com/products/kong-konnect)complete SaaS API management platform. All of the code we will look at in this post is available in the [KongAir GitHub repository](https://github.com/Kong/KongAir/blob/main/experience/kong/experience-service.yaml)KongAir GitHub repository.
Services, routes and plugins are configured using a combination of OpenAPI specifications and decK declarative format. Let’s start by looking at the decK declarative definition that configures our GraphQL service:
services:
- host: experience.kongair
id: f1c41796-5c88-419b-a391-baa0c2f62f0d
name: experience-service
path: /
plugins:
...
port: 8084
protocol: http
routes:
- id: 52cc7a8f-8914-46aa-990d-ad07197d7fc9
methods:
- POST
name: experience-service_query
paths:
- ~/query$
plugins: []
...The above is a snippet from a partial decK file that includes a Kong Gateway service declaration for our GraphQL service. This section specifies the connectivity details allowing our Kong Gateway to proxy traffic to our upstream GraphQL service. The route matches the URL path our GraphQL service listens on /query.
Next, let’s focus on the GraphQL plugins we associate with this service, from the same file:
...
plugins:
- _config: default-jwt
enabled: true
name: jwt
- name: graphql-proxy-cache-advanced
config:
strategy: memory
cache_ttl: 15
- name: graphql-rate-limiting-advanced
config:
limit:
- 500
window_size:
- 120
sync_rate: -1
...We’ve associated 3 plugins with our GraphQL service:
jwt plugin allows us to protect the service by requiring and validating JSON Web Tokens. The configuration for this plugin is shared with other services in the KongAir system, and the decK [config de-duplication feature](https://docs.konghq.com/deck/latest/guides/deduplicate-plugin-configuration/)config de-duplication feature is used via the _config key, which indicates a shared configuration.graphql-proxy-cache-advanced configuration provides caching services for any request bound for the experience service. In this example, we configure the plugin to store cached responses in memory and expire them after 15 seconds.graphql-rate-limiting-advanced plugin is installed and is configured with a request cost limit of 500 per 120-second window. Limits are calculated by default per Consumer, but can be modified to be per IP address or credential.The complete file is available [in the GitHub repository](https://github.com/Kong/KongAir/blob/main/experience/kong/experience-service.yaml)in the GitHub repository.
As mentioned earlier, KongAir uses decK and APIOps to automate the delivery of APIs to Kong Gateway. GitHub actions are used along with various decK APIOps features, to assemble a final declarative configuration and synchronize it to Kong Gateway.
The relevant command that merges our experience API definition looks like the following:
deck file merge \
.github/artifacts/kong/kong-combined.yaml experience/kong/experience-service.yaml \
-o .github/artifacts/kong/kong-combined.yamlThese commands are part of a broader set of GitHub actions to assemble, validate, and deploy the configuration. The above command can be found in the [stage-changes-for-kong.yaml](https://github.com/Kong/KongAir/blob/main/.github/workflows/stage-changes-for-kong.yamld48d76d26b/.github/workflows/stage-changes-for-kong.yaml)stage-changes-for-kong.yaml file.
These APIOps workflows follow a GitOps style methodology and use GitHub Pull Requests to stage changes to the KongAir production system.
Using these technologies together allows a combination of automation and human oversight to ensure auditable and accurate changes to the gateway configuration.
The KongAir APIOps automation deploys to a Kong Konnect managed Kong Gateway. Konnect provides KongAir a full API management solution. Here are some example benefits of the Konnect platform.
Using Konnect’s Gateway Manager, we have clear visual displays showing our deployed security and GraphQL traffic management plugins. From this display, we can investigate all aspects of the plugins ensuring proper configuration and deployment.
Konnect’s Analytics capabilities allow us to gain further insight into our API usage. Customized reports allow us to focus on individual API metrics important to the observability of our system.
Now that we have deployed the GraphQL native plugins in front of our GraphQL API, let’s verify they are working as expected from the client's perspective.
When a client makes a GraphQL request now, they are subject to the rate-limiting plugin and may benefit from a cache hit on their request. For example, here is an example query showing the return headers from Kong.
curl -v -X POST \
-H 'Accept: application/json' -H 'Content-Type: application/json' \
-H "Authorization: Bearer $DFREESE" https://api.kong-air.com/query \
--data '{ "query": "{ me { username bookings { ticket_number seat flight { number route { origin destination } } } } }" }'
< HTTP/2 200
< content-type: application/json; charset=utf-8
< content-length: 288
< x-gql-query-cost: 12
< x-ratelimit-limit-120: 500
< x-ratelimit-remaining-120: 488
< x-cache-key: e503b3d864bd24c16305374e776fd76cc572193824156454965bda281102beaf
< x-cache-status: Miss
< x-powered-by: Express
< access-control-allow-origin: *
< cache-control: no-store
< etag: W/"120-cDCLTDDn5X4w99qmGvfg2ZFSpUc"
< date: Thu, 05 Oct 2023 19:28:02 GMT
< x-kong-upstream-latency: 70
< x-kong-proxy-latency: 44
< via: kong/3.4.0.0-enterprise-edition
<
{"data":{"me":{"username":"dfreese","bookings":[{"ticket_number":"RIN74XEJWG","seat":"18A","flight":{"number":"KA0288","route":{"origin":"LHR","destination":"BOM"}}},{"ticket_number":"RDAWJ63VAP","seat":"19C","flight":{"number":"KA0289","route":{"origin":"LHR","destination":"HND"}}}]}}}
* Connection #0 to host api.kong-air.com left intact
From the response headers, you can see the plugins in action.
The rate-limiting plugin has calculated the cost of our request at 12, reported in the x-gql-query-cost header. This value is calculated using the [default strategy for cost calculation](https://docs.konghq.com/hub/kong-inc/graphql-rate-limiting-advanced/api/)default strategy for cost calculation.
The GraphQL caching plugin has also responded with headers indicating its processing of the request. In the response, we see that a cache key for our request has been calculated and reported in the x-cache-key header. In this example, it was determined there was a cache miss which is indicated in the header x-cache-status. If a *Consumer* makes a duplicate request within the plugin’s cache_ttl time constraint, you would see x-cache-status: Hit instead.
Governing GraphQL APIs is critical to your system's availability and robustness. Kong Gateway provides core GraphQL native plugin capabilities for rate limiting and response caching. These plugins paired with Kong Konnect provide a full-featured unified API management solution for your GraphQL services. For more advanced usage of GraphQL with Kong, see our solution page on [next generation API platforms with Kong and Apollo](https://konghq.com/blog/news/apollo-and-kong-blueprint)next generation API platforms with Kong and Apollo and get started with Kong Konnect today [for free](https://konghq.com/products/kong-konnect)for free.
Traditional APIs are, in a word, predictable. You know what you're getting: Compute costs that don't surprise you Traffic patterns that behave themselves Clean, well-defined request and response cycles AI APIs, especially anything that runs on LLMs
[](https://konghq.com/blog/engineering/monetize-ai-apis)
Today, we’re excited to release the Kong Konnect EKS Marketplace add-on as a means to deploy your Kong Gateway dataplanes in AWS. The add-ons are a step forward in providing fully managed Kubernetes clusters. It is here to simplify the post-procurem
[](https://konghq.com/blog/engineering/kong-konnect-eks-marketplace-add-on)
In the Kubernetes world, the Ingress API has been the longstanding staple for getting access to your Services from outside your cluster network. Ingress has served us well over the years and can be found present in several dozen different implementa
[](https://konghq.com/blog/engineering/gateway-api-from-early-years-to-ga)
While JSON-based APIs are ubiquitous in the API-centric world of today, many industries adapted internet-based protocols for automated information exchange way before REST and JSON became popular. One attempt to establish a standardized protocol sui
[](https://konghq.com/blog/engineering/soap-to-json-with-kong-gateway)
Jeff Broberg, William Seaton and Peter Sullivan from Styra also contributed to this post API Gateway Authentication (AuthN) and Authorization (AuthZ) are important ways to control the data that is allowed to be transmitted using your APIs. Basically
[](https://konghq.com/blog/engineering/kong-gateway-enterprise-and-styra-das)
There are many pros and cons for both GraphQL and REST APIs, but one of the areas where GraphQL really shines is API composition. Taking data from multiple APIs and combining them to make something new is a key part of delivering a useful service.
[](https://konghq.com/blog/engineering/api-composition-with-stepzen-and-kong)
The Kong Laboratory – Kong API Gateway The quest for resilience and agility has driven us into the modern age of microservices. Bringing services to market on a microservice architecture demands the utilization of sprawling technology offerings and
[](https://konghq.com/blog/engineering/kong-api-gateway-on-kubernetes-with-pulumi)