Nesting the GitHub API schema in my own

[mattkrick]

I'd like to put GitHub's schema inside my own so I can make a call that looks like this:

{
  viewer {
    accessToken
    github {
      # This part is from GitHub
      viewer {
        bio
      }
    }
  }
}

My strategy is to rename all the GitHub types with a _GitHub prefix.
Unfortunately, I think I must be using the transform wrong because the error I receive is Definitions of field "_GitHubQuery.viewer" implement inconsistent named types across subschemas.

I've tried both mergeSchema and stitchSchema with similar results. Could someone help point me in the right direction?
Example code below:

const parentSchema = makeExecutableSchema({
  typeDefs: `
type User {
  accessToken: String!
}
type Query {
  viewer: User
}
`,
  resolvers: {
    Query: {
      viewer: () => {
        return {
          accessToken: 'gho_YOURTOKENHERE'
        }
      }
    }
  }
})

const rawGitHubSchema = makeExecutableSchema({
  typeDefs: schema.idl
})

const executor = async ({document, variables, context}) => {
  const {accessToken} = context
  const query = print(document)
  const fetchResult = await fetch('https://api.github.com/graphql', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      Authorization: `Bearer ${accessToken}`,
      Accept: 'application/json'
    },
    body: JSON.stringify({query, variables})
  })
  return fetchResult.json()
}

const prefixGitHub = (name: string) => `_GitHub${name}`
const transforms = [new RenameRootTypes(prefixGitHub), new RenameTypes(prefixGitHub)]

const githubSubSchemaConfig = {
  schema: rawGitHubSchema,
  executor,
  transforms
}

const mergedSchema = stitchSchemas({
  subschemas: [
    githubSubSchemaConfig,
    {
      schema: parentSchema
    }
  ],
  mergeTypes: false,
  typeDefs: `
  extend type User {
    github: _GitHubQuery
  }
  `,
  resolvers: {
    User: {
      github: {
        selectionSet: `{ accessToken }`,
        resolve: async ({accessToken}, args, context, info) => {
          return delegateToSchema({
            schema: githubSubSchemaConfig,
            operation: 'query',
            fieldName: 'relay',
            args,
            context: {
              ...context,
              accessToken
            },
            info
          })
        }
      }
    }
  }
})

[yaacovCR]

Welcome!

one thing, i don’t believe you want to rename the root types, all root types should be the same so things merge properly.

That transform is for subschemas that don’t use Query. Not sure what GitHub uses.

also not sure why you are getting that exact error message....

Note that the WrapType transform can be used on a remote schema to namespace a root type’s fields under a field rather than using manual delegateToSchema

[yaacovCR]

Looks like you solved it, I am glad!!

of note, we have a batch execute package that can turn any executor into a batching executor. Not sure if more or less robust than yours, would be good to compare at some point, reminder you self

you are merging a wrapped schema rather than using stitchSchemas, which is fine if it works for you, but does mean you can’t use type merging (although your use of prefixing kind of means that how you want it)

[yaacovCR]

And how do you ensure works when access token not in query without selectionSet hints from stitching?

[mattkrick]

Thank you!
I wasn't able to reuse the batching executor just because I did some special error handling like path-based filtering.

For the access token, the DX is to accept a GraphQLFieldResolver<ParentType> callback & let the dev decide how to get it. For example, if I'm nesting the API on the User object, the callback might be (source) => getTokenForUserId(source.userId)

[yaacovCR]

Does our batching executor not send errors to correct place based on path?

[yaacovCR]

Note also that you can pass a createProxyingResolver function as part of arguments to wrapSchema, just fyi

[yaacovCR]

Right, but when you are nesting, how do you ensure userId is present if was not requested

…

On Thu, 29 Apr 2021 at 20:43 Matt Krick ***@***.***> wrote: Thank you! I wasn't able to reuse the batching executor just because I did some special error handling like path-based filtering. For the access token, the DX is to accept a GraphQLFieldResolver<ParentType> callback & let the dev decide how to get it. For example, if I'm nesting the API on the User object, the callback might be (source) => getTokenForUserId(source.userId) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2878 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA7LAYCH2XOFG54G3E25LLLTLGLEJANCNFSM43WAAOEQ> .

[mattkrick]

Ah, I'm sorry I'm not sure I understand.
The userId never needs to be requested because it lives on the source (or in args or context, depending on how it's set up).

[yaacovCR]

Got it, thanks