GraphQL Gateway Architectures

转自： https://tomasalabes.me/blog/graphql/node/microservices/2018/08/11/graphql-architectures.html

GraphQL Gateway Architectures

These are the approaches we will see:

Remote Schema Stitching
Schema Stitching through Shared Interfaces
Hybrid Remote Schema Stitching
Using Prisma’s graphQL Bindings

Let’s start.

Remote schema stitching

Stitching strategy

The gql gateway builds the schema exposed to the client as a mashup of many remote graphql schemas (link)
- This lets the graphql servers evolve independently from the gateway but
The dynamic nature of this can be tricky, as the final API is “dispersed”, interaction between schemas can become complicated, maybe needing the following:
- You might have merge conflicts (more) or transformations (more)
- Without proper testing, remote schemas might change and the gateway becomes out of date / broken
All services that expose some graphQL schema will be a graphQL server, exposing the usual /graphql endpoint.
Each service can choose in what language implement the graphQL server

Schema stitching through shared interfaces

NPM interfaces strategy

The gql gateway builds the schema exposed to the client as a mashup of many local graphql schemas (more)
These schemas are installed as npm packages
Development is easier as you have the schemas installed locally and you have the “source of truth” for the final API
The gateway will became a bottleneck, being modified by many teams as it has all resolvers and types
A change in any resolver or schema means redeploying the gql gateway and the service (high cohesion)

Hybrid Remote Schema Stitching

Hybrid resolvers strategy

This is a very simple variation from the previous 2 architectures. It’s just being able to not only delegate requests to other graphQL servers through schema stitching but also contain resolvers for other services.

The graphQL gateway communicates with Service A through a resolver implementation in the gateway itself (approach #2)
The graphQL gateway communicates with Service B through schema stitching (approach #1)

Using Prisma’s graphQL Bindings

This approach uses prima’s graphQL bindings. Think of it as a client built from a graphQL schema and its resolvers.

Prisma Bindings

So the collaboration diagram would be something like

Bindings strategy

Where

Service A and B publish a binding with all the resolvers for their types, queries and mutations
These bindings are consumed by the gateway and used to communicate with these services
This avoids the actual resolvers implementation in the gateway, and even in the services themselves
The development of the resolvers is done by the team developing the service in question