Remote Schemas
For services that do provide a GraphQL API, we stitch their APIs into our own GraphQL schema – a technique called schema stitching.
Stiching vs Federation
For the more savy GraphQL engineers, they might wonder why we use stitching over Federation. In short, we don't use Federatiom because it requires that every combined schema be aware of the existence of other schemas – which doesn't happen when we are merging independent external APIs.
You can learn more on the differences on this blog post.
In the STRV Website, for instance, DatoCMS's schema has no awareness of the other schemas in use by our application, and therefore is not interoperable with them by default.
Implementation
GraphQL Modules provides schema stitching in it's core. It allows us to create a GraphQL application that converges both local schemas with external ones easily.
External schemas
Each external schema is represented by an object containing two properties:
| Name | Description |
|---|---|
schema | A non-executable GraphQLSchema instance, defining the types and their fields. |
executor | A functional capable of receiving an operation partial and resolving it's result on top of the provided schema. |
The implementation of the executor will vary depending on how we intend to connect to the external schema. Generally speaking, it would behave much like an Apollo HTTP Link, resolving it's given operation using a GET/POST request to a GraphQL API.
However, we can resolve the operation partial in many other ways. In the STRV Website, for instance, we have a DatoCMS schema representation being fully loaded locally, using a build-time generated introspection of that schema. Operations against this schema are executed using a traditional Apollo link, configured as one would if DatoCMS was the only schema to connect to.
See: ./datocms/index.ts