Schema stitching & extending Redwood

Hey folks!

Has anyone here gotten schema stitching working with Redwood? There are a few external GraphQL API services that I’d like to expose to the client, and I’d prefer to do it through a single unified API endpoint. Any tips or tricks would be greatly appreciated!

I might be missing something here about your specific case, but Redwood does it’s own schema merging using makeMergedSchema. This is implemented in api/src/functions/graphql.js. (Admittedly, we could use a good Doc about this.)

For an example, take a look at the Cookbook Using a Third Party API, specifically the section “The Service” where the file api/src/services/weather/weather.js is defined. (Example code is here.)

Does this seem like it will help with your requirements?

The Third Party API Cookbook example is a great example to how to expose an arbitrary API (in that case a RESTful one) and make it available as part of the Redwood GraphQL API.

However, it requires the developer to write SDL for the service and implement invocation. This is relatively simple for the example in the cookbook, but would be painful if trying to stitch a large 3rd party API.

The example from the Apollo docs shows how to retrieve and introspect a remote schema. It would be awesome to figure out how to do this and then stitch/merge it with the rest of the GraphQL API being created by Redwood. I have not been able to figure it out on my own, yet.

const { HttpLink } = require('apollo-link-http');
const fetch = require('node-fetch');
const { introspectSchema, makeRemoteExecutableSchema } = require('graphql-tools');

const link = new HttpLink({ uri: 'http://api.githunt.com/graphql', fetch });

const schema = await introspectSchema(link);

const executableSchema = makeRemoteExecutableSchema({
  schema,
  link,
});
1 Like

@peterp This is an intriguing feature that comes with Apollo.

I’m spitballing here, but given this example from the Apollo docs it looks possible to:

  1. create a new SDL file in api/src/graphql/
  2. export const schema = mergeSchemas(...)
  3. which will then be included in the graphql.js via makeMergedSchema

I’m taking for granted the structure will be the same, but if it’s a gql SDL… ?

And/or what about adding these “stiched schemas” as a new function file alongside graphql.js?

I think a possible problem here is if you are doing schema inference, it will come in asynchronously. makeMergedSchema and mergeSchemas assume that you already have the structure laid out statically in your SDLs.

I just started looking into dynamically stitching a 3rd party GraphQL API into RedwoodJS and that is what I’m running into. I don’t think this would be possible unless you infer either during lambda execution or build time to grab the structure. Or create a stitch “migration” service similar to the Prisma migration service but specifically for GraphQL external SDLs.

But I probably missed something so take what I say with a grain of salt. This issue reminds me of that old Rails library that recorded JSON payload for tests called VCR so you could have a sanity check that your internal endpoints were adhering to external contracts.