API Facade Pattern for GraphQL APIs

The API Facade Pattern can be used to expose a subset or variant of a GraphQL API.

Problem

Let's say you've implemented a GraphQL API and want to expose a subset of this API to a third party. Your GraphQL server might expose some internal fields that you don't want to expose to the third party, or you might want to rename some fields before exposing them. In this case, you can implement an API Facade that exposes a subset of your API.

Solution

The API Facade pattern is implemented by creating a GraphQL API Gateway that only exposes a subset of the fields of the original API.

By doing so, an introspection Query will only reveal the subset of the API that is exposed. At the same time, if a client requested a field that is not exposed by the API Facade, the API Gateway will return an error to the client as the Operation Validation will fail.

In case of renaming fields, the API Gateway needs to be aware of the original field name. If a client requests such a renamed field, the API Gateway will need to parse the GraphQL Operation, replace the renamed field with the original field name, and forward the Operation to the original API. Not doing so will result in a validation error as the original API will not know the renamed field.

Example

Let's say we have a GraphQL API that exposes a User type with the following fields:

type User {
  id: ID!
  name: String!
  email: String!
  password: String!
}

We want to expose a subset of this API to a third party. We don't want to expose the password field, and we want to rename the email field to mail.

We can implement an API Gateway that exposes the following User type:

type User {
  id: ID!
  name: String!
  mail: String!
}

The API Gateway will need to parse the GraphQL Operation, replace the mail field with email, and forward the Operation to the original API.