What are the differences between a GraphQL API Gateway and a regular API Gateway?
Does it even make sense to have a dedicated GraphQL API Gateway? Could we not just extend a regular API Gateway to support GraphQL? Where can we draw the line between a regular API Gateway and a GraphQL API Gateway?
You might have questions like these in your mind. Let's try to answer them. To do so, let's take a step back and start from the bottom up. I see the GraphQL API Gateway as an evolution of the API Proxy and API Gateway patterns.
What is an API Proxy?
The API Proxy is a pattern that is used to expose an API or service to the outside world. The API Proxy is usually a thin layer that is responsible to forward requests to the actual API or service. It might have additinal responsibilities like IP filtering and other security related tasks, but it's rarely responsible for anything that touches the application layer.
What is an API Gateway?
The API Gateway is a pattern that is used to expose multiple APIs or services to the outside world. An API Gateway has usually the following responsibilities:
- Routing
- Authentication
- Authorization
- Rate Limiting
- Logging
- Monitoring
- Caching
- Transformation
- Versioning
Most API Gateways are optimized for REST APIs, so the central point to define a resource is usually the URL. Most API Gateways don't look at the payload of the request to determine what operations to perform. Based on the URL, the API Gateway will apply policies, delegate authentication, etc...
API Gateways can usually be found in larger organizations that have a lot of APIs and services. In such an architecture, it makes sense to "outsource" the above listed cross-cutting concerns to a dedicated component.
The differentiation between regular API Gateways and GraphQL API Gateways
As mentioned above, I understand the GraphQL API Gateway as an evolution of the API Gateway pattern. GraphQL is a query language for APIs, and therefore it's a perfect fit for API Aggregation and API Composition.
Two components of the GraphQL Specification are especially interesting in this context:
The GraphQL Schema Definition Language (SDL)
The SDL is a language that is used to define the GraphQL Schema. It allows us to define our service architecture in a declarative way. We've able to map out the relationships between our services and define the types that are exposed by our services.
The GraphQL Query Language, Selection Sets and Fragments
The GraphQL Query Language is a language that is used to query the GraphQL API. It allows us to define the data that we want to retrieve from the GraphQL API.
What's special about GraphQL is that we're able to use Selection Sets and Fragments to define the data that we want to retrieve.
That's especially useful in an environment where we have to deal with multiple APIs and services.
It's possible to have a Schema that builds circular dependencies.
E.g. you could have a User type that has a friends field of type [User].
Using Selection Sets and Fragments, we're able to define the "subset" of data from our data graph that we're interested in.
Here's an example:
query {
user(id: "1") {
id
name
friends {
id
name
}
}
}In this example, we're querying the user field of the root type Query.
In theory, friends could have a friends field as well,
but we're not "slecting" that field in our query.
If you consider that each user or friends field could be backed by another API call to a Microservice,
it becomes clear that GraphQL is a great fit for API Aggregation and API Composition.
What makes GraphQL API Gateways special?
The above points are exactly what makes GraphQL API Gateways special over regular ones. Instead of simply exposing a REST API as is, with protection and policies applied, GraphQL API Gateways don't just do the same for GraphQL APIs.
GraphQL API Gateways are a paradigm shift. With this new pattern, we're able to achieve two main goals:
- We're able to build APIs in a more modular way, but still expose them as a single monolithic API.
- We can offload the complexity of API Aggregation to the Gateway, which reduces complexity in the client application and reduces the number of roundtrips.
GraphQL API Gateways enable a paradigm shift to build APIs in a more modular way
With GraphQL API Gateways, it's becoming much easier to compose an API from multiple APIs and services. With a traditional API Gateway, we're usually exposing the APIs and services without any aggregation, so this task is still left to the client application, which might be costly if we're adding latency between the client and the API Gateway.
If a client application wants to retrieve data from multiple APIs,
and these API calls depend on each other, like user and friends,
the client application has to make multiple roundtrips to the API Gateway to retrieve the data.
GraphQL API Gateways move the complexity of API Aggregation to the Gateway
With a GraphQL API Gateway and the API Aggregation Pattern, we're able to reduce the number of roundtrips to the API Gateway, while still being able to implement the API in a modular way. E.g. two teams could work on two different APIs, and the GraphQL API Gateway could expose both APIs as a single API.
GraphQL API Gateways enable MACH Architectures
MACH stands for Microservices, API-first, Cloud-native, Headless, the pillars of a modern composable architecture. What's essential for a MACH Architecture is that we've got a powerful API composition layer.
When your application stands of the shoulders of Microservices and API-first SaaS Providers, a huge part of your application is to compose and integrate different services.
Instead of heaving to build or buy a monolithic solution, MACH architectures allow you to decompose your application into smaller pieces, and buy APIs and services off the shelf when applicable.
Conclusion
GraphQL API Gateways are a paradigm shift in the way we build APIs. They are an enabler for composable Architectures like MACH and help organizations scale their API Strategy across teams and departments.
Instead of having to build or buy monolithic solutions, GraphQL API Gateways allow you to build and buy modular solutions to specific problems and integrate them into your application.