Type merging
Consolidate the schema definitions, including overlapping type definitons, and resolvers from multiple subschema instances into a stitched schema.
When you merge multiple API subschema into one stitched schema, you might have one type that is defined in multiple subschemas. To ensure that only one reconciled type exists for the stitched schema, and that it contains all the necessary fields across each subschema, you use type merging.
To enable type merging, you create a Gloo GraphQLStitchedSchema
custom resource that references each GraphQL API subschema. Within the subschemas that contain a shared type, you specify the type name, and the set of partial fields that the subschema provides. Gloo Mesh Gateway uses this resource to generate a stitched schema, which incorporates all the partial types from each of the respective services. When clients query the route for the stitched schema, Gloo Mesh Gateway creates requests to the individual services, and then stitches the responses back together into one response to the client. For more information, see What is GraphQL stitching?.
Overlapping type example
To understand overlapping schema types, suppose that you want to merge the subschema for two APIs: the users service and the accounts service.
In the users service ApiDoc
, you might define the following GetUser
query to retrieve a user by a query-supplied username
. The User
type defines the username
, firstname
, and lastname
fields.
...
type Query {
GetUser(username: String): User
}
type User {
username: String
firstName: String
lastName: String
}
In the accounts service ApiDoc
, you also have a User
type. Unlike the users service, however, the accounts service’s User
type is partial, and has only the username
field.
...
type Account {
owner: User
}
type User {
username: String
}
To ensure that the accounts subschema can provide its partial User
type (with only the username) and have access to the full set of User
type fields, you provide the relevant information from the type as it is fully defined in the users subschema. In the reference for the users subschema in your GraphQLStitchedSchema
CR, you provide the following typeMerge
section:
...
subschemas:
- schema:
name: users-subschema
namespace: customers
clusterName: cluster1
typeMerge:
User:
selection_set: '{ username }'
query_name: 'GetUser'
args:
username: username
- schema:
name: accounts-subschema
...
The resultant stitched schema can now provide the full User
type definition to all partial User
types in other APIs that require it. In this case, you can now retrieve, for example, the first name of a user from the Account.owner
field, even though the accounts schema doesn’t provide the first name from the User
type in its own ApiDoc
CR.
Merge GraphQL schema and types
For each API, define schema and select resolver services in your Gloo environment. Then, you can merge the GraphQL APIs together and merge overlapping types in a GraphQLStitchedSchema
, and set up routing to this merged resolver. Note: Type merging is not supported for mutation and subscription types.
The examples in this guide are based on the Bookinfo sample app. To check out individual resources you might create for a stitched Bookinfo schema that uses type merging, check out the Gloo custom resources in the Gloo sample repository.
For each subschema, use the following guides to create individual CRs for each API that define its schema and resolvers.
- Define subschema in separate
ApiDoc
CRs. For the Bookinfo example, you might define three CRs for the product, reviews, and ratings services. - Choose how GraphQL requests are executed, and follow the guides to either proxy requests to existing GraphQL backends or define REST, gRPC, or mock resolvers for each schema.
- Define subschema in separate
Create one
GraphQLStitchedSchema
CR that references each GraphQL subschema. For each overlapping type, specify the partial fields that the type provides in each subschema. For example, in this stitched schema for Bookinfo, the schema references for ratings and reviews specify theid
type that each subschema contains. For eachtypeMerge
, the partial fields that each subschema provides for theid
type are specified in theselectionSet
.apiVersion: apimanagement.gloo.solo.io/v2 kind: GraphQLStitchedSchema metadata: name: stitched-graphql-schema namespace: bookinfo spec: subschemas: - schema: clusterName: $CLUSTER_NAME name: products-graphql-schema namespace: bookinfo - schema: clusterName: $CLUSTER_NAME name: ratings-graphql-schema namespace: bookinfo typeMerge: Ratings: args: id: id queryName: GetRatings selectionSet: '{ id }' - schema: clusterName: $CLUSTER_NAME name: reviews-graphql-schema namespace: bookinfo typeMerge: Reviews: args: id: id queryName: GetReviews selectionSet: '{ id }'
Create a route table that routes to a
graphql.stitchedSchema
destination. Specify your stitched schema resource name in thegraphql.stitchedSchema.name
field, such asstitched-graphql-schema
in the following examples.Test routing to your stitched resolver setup.
Reference
For more information, see the Gloo Mesh Gateway API reference for the GraphQLStitchedSchema
CR.