GraphQL API Gateway use Cases

Here's on overview of the typical use cases for GraphQL API Gateways.

Protecting an existing GraphQL API

One of the most common use cases for GraphQL API Gateways is to protect an existing GraphQL API. This can take many forms, but the most common is to add a layer of security by validating incoming requests, adding an authentication layer, and apply rate limiting and quotas before forwarding the request to the underlying GraphQL API.

Applying patterns like rate limiting and quotas might seem trivial at first, but it's actually quite complex, considering that GraphQL requests can ask for arbitrary levels of nested data. This means that a single GraphQL request can result in hundreds of requests to the underlying GraphQL API. Read more on this in the Rate Limiting and Quotas section.

In addition to what cloud be considered obvious security measures, GraphQL API Gateways can also ensure in other ways that upstream services are not overloaded. E.g. by applying Normalization together with the single-flight pattern, the Gateway can ensure that the upstream is not overloaded with duplicate requests for the same data.

Aggregating / Stitching / Federating multiple GraphQL APIs

Another common use case for GraphQL API Gateways is API aggregation or API composition, in GraphQL terms this is often referred to as Schema Stitching or Federation.

In this scenario, the GraphQL API Gateway acts as a facade for multiple GraphQL APIs, and is responsible for aggregating the data from the underlying APIs into a single GraphQL schema.

Both Schema Stitching and Federation are quite powerful patterns and serve slightly different purposes. With Schema Stitching, the Gateway is responsible for composing a Schema of multiple underlying GraphQL APIs. In this scenario, the underlying APIs are not aware of the Stitching. Federation on the other hand is a pattern where the underlying APIs are aware that the Gateway is aggregating them, which means that individual services might share types and fields. If you'd like to learn more about the two patterns, check out their individual sections.

Protocol Translation for non-GraphQL APIs

It's a complex task to integrate multiple APIs in an application, but even more so when the APIs are using different protocols. That's where API Gateways can shine when they support protocol translation.

As mentioned in the into to this website, GraphQL is a great fit for API Aggregations and API Composition, but what if the underlying APIs don't speak GraphQL but instead use REST or SOAP?

In this scenario, the GraphQL API Gateway can apply the Protocol Translation Pattern. This pattern allows you to unify multiple heterogenous APIs into a single unified GraphQL API. This greatly simplifies the integration of multiple APIs into an application, and keeps the application code clean and easy to maintain.

Persisting GraphQL Operations / Queries

It might be seens as a feature, but I think it's one of the most important responsibilities of a GraphQL API Gateway, I'm talking about persisting GraphQL Operations.

In a production-grade GraphQL deployment, GraphQL Operations should always be persisted at deployment time. That is, client applications should not be able to send arbitrary GraphQL Operations to the Gateway at runtime. Instead, the Operations should be pre-registered (persisted) ahead of time. This doesn't just make the Gateway more secure, as we're no longer exposing the GraphQL API to the public, but it also allows us to improve the performance and reduce the amount of network traffic. There's a lot more to this, so I recommend you read the Persisted Operations section to learn more about this pattern.