Overwriting field resolution

[tichopad]

Hey everyone!

I'm using schema stitching to setup a gateway that merges a remote schema and a local one.

The local schema extends the remote schema types with additional fields. This part works great.

But the local schema also overwrites existing remote schema fields. I need to be able to define the local schema as the canonical source of truth for specific fields on specific types. This is what I'm struggling to figure out.

I tried marking the fields and/or parent types as canonical but to no avail.
I also tried using onTypeConflict to resolve it manually, but I'm not really sure how to leverage it. And I don't want to turn the automatic type merging off, because it's useful for other cases.

Please does someone have any pointers? Am I trying to do something Schema Stitching isn't meant to do?

Here's an example setup I'm using:

# Remote schema definition
type Query {
  user(id: ID!): User
}
type User {
  id: ID!
  name: String
  age: Int
}

// Local schema definition
const localSchema = createSchema({
  typeDefs: `
    type Query {
      getUserById(id: ID!): User
    }
    type User {
      id: ID!
      name: String @canonical # This doesn't seem to affect the resolution the way I think it does
      intro: String!
    }
  `,
  resolvers: {
    Query: {
      getUserById: (_, { id }) => ({ id }),
    },
    User: {
      intro: () =>  'Hello!',
      name: () => 'Velma', // I want this to take precedence over the remote schema
    },
  },
});
// Stitched schema
const stitchedSchema = stitchSchemas({
  subschemas: [
    {
      schema: remoteSchemaDefinition,
      executor: remoteSchemaExecutor,
      batch: true,
      merge: {
        User: {
          selectionSet: '{ id }',
          fieldName: 'user',
          args: ({ id }) => ({ id }),
        },
      },
    },
    {
      schema: localSchema,
      batch: true,
      merge: {
        User: {
          selectionSet: '{ id }',
          fieldName: 'getUserById',
          args: ({ id }) => ({ id }),
        },
      },
    },
  ],
});

[tichopad]

Looks like the stitched schema definition's resolver has precedence over whatever sub-schemas return, so it seems I could use it, but that goes against the local schema being the source of truth.

const stitchedSchema = stitchSchemas({
  subschemas: [
    {
      schema: remoteSchemaDefinition,
      executor: remoteSchemaExecutor,
      batch: true,
      merge: {
        User: {
          selectionSet: '{ id }',
          fieldName: 'user',
          args: ({ id }) => ({ id }),
        },
      },
    },
    {
      schema: localSchema,
      batch: true,
      merge: {
        User: {
          selectionSet: '{ id }',
          fieldName: 'getUserById',
          args: ({ id }) => ({ id }),
        },
      },
    },
  ],
  resolvers: {
    User: {
      name: {
        selectionSet: '{ id }',
        resolve: () => 'Velma', // Works, but takes control away from the local schema
      },
    },
  },
});

[ardatan]

Canonical directive is part of stitching directives. If you want to mark fields as canonical programmatically, you can use "merge";

merge: {
   User: {
      fields: {
          name: {
              canonical: true
          }
     }
}

[tichopad]

Thanks for responding, dude!

This should be equivalent to @canonical directive if I'm not mistaken. I tried it already just to make sure, but it doesn't really do anything in this case. But that can still mean I'm doing something wrong.

Just to be clear - "canonical" is intended to override resolved values as well, and not just type/field definitions, right?

[ardatan]

Yes but in order to use stitching directives, you have to setup them;
https://the-guild.dev/graphql/stitching/docs/approaches/stitching-directives#gateway-setup
You can't just use them without this setup

If it still doesn't work for you, could you create a reproduction or a failing test in a PR so we can help you better :) ?
Thanks!

[tichopad]

Sorry! I should've started with that 😅 !

Here's a trimmed-down repro - https://stackblitz.com/edit/stackblitz-starters-95oft6?file=main.js

Both remote and local schema define User.name property. Local schema's definition is marked canonical, but the resolved value is always the remote one.

And the repro code for future reference

import { createSchema, createYoga } from 'graphql-yoga';
import { createServer } from 'node:http';
import { stitchSchemas } from '@graphql-tools/stitch';
import { schemaFromExecutor } from '@graphql-tools/wrap';
import { buildHTTPExecutor } from '@graphql-tools/executor-http';
const users = [

{ id: '1', name: 'Fred', age: 30 },

{ id: '2', name: 'Velma', age: 32 },

];

const remoteSchema = createSchema({

typeDefs: /* GraphQL */ type Query { getUser(id: ID!): User } type User { id: ID! name: String age: Int },

resolvers: {

Query: {

getUser: (_, { id }) => users.find((u) => u.id === id),

},

},

});

const remoteYoga = createYoga({ schema: remoteSchema });

const remoteServer = createServer(remoteYoga);

remoteServer.listen(4000);
export const localSchema = createSchema({

typeDefs: /* GraphQL */ type Query { getUser(id: ID!): User } type User { id: ID! name: String },

resolvers: {

Query: {

// Stubbed resolver

getUser: (_, { id }) => ({ id }),

},

User: {

// ⚠️ Local schema's User.name is marked canonical, but this resolver doesn't overwrite the value

name: () => 'OVERWRITE',

},

},

});
const remoteSchemaExecutor = buildHTTPExecutor({

endpoint: 'http://localhost:4000/graphql',

method: 'POST',

});
const stitchedSchema = stitchSchemas({

subschemas: [

{

schema: localSchema,

merge: {

User: {

selectionSet: '{ id }',

fieldName: 'getUser',

args: ({ id }) => ({ id }),

fields: {

name: {

canonical: true,

},

},

},

},

},

{

schema: await schemaFromExecutor(remoteSchemaExecutor),

executor: remoteSchemaExecutor,

merge: {

User: {

selectionSet: '{ id }',

fieldName: 'getUser',

args: ({ id }) => ({ id }),

},

},

},

],

});

const gatewayYoga = createYoga({

schema: stitchedSchema,

graphiql: {

defaultQuery: /* GraphQL */ { getUser(id: "2") { id name age } },

},

});

const gatewayServer = createServer(gatewayYoga);

gatewayServer.listen(4001, () => {

console.info(

'Gateway server is running. Visit http://localhost:4001/graphql'

);

});

[tichopad]

Alright, I figured it out.

First, what I'm trying to accomplish is similar to Apollo's @override directive. I want to be able to specify which subschema should be used for a resolutiuon of a specific duplicate field.
I'm using this to migrate away from a monolith API.

I could not achieve this using canonical definitions.

However, I figured my intended functionality works under two conditions:

1. The canonical subschema is ordered last in the subschemas array
2. Both the original and the overwriting type merge option is using the exact same fieldName

For example, this works:

const stitchedSchema = stitchSchemas({
  subschemas: [
    {
      schema: await schemaFromExecutor(remoteSchemaExecutor),
      executor: remoteSchemaExecutor,
      merge: {
        User: {
          selectionSet: '{ id }',
          fieldName: 'getUser',
          args: ({ id }) => ({ id }),
        },
      },
    },
    // localSchema is placed last in the array
    {
      schema: localSchema,
      merge: {
        User: {
          selectionSet: '{ id }',
          fieldName: 'getUser', // The fieldName is exactly the same as the remote schema
          args: ({ id }) => ({ id }),
        },
      },
    },
  ],
});

This does not:

const stitchedSchema = stitchSchemas({
  subschemas: [
    {
      schema: await schemaFromExecutor(remoteSchemaExecutor),
      executor: remoteSchemaExecutor,
      merge: {
        User: {
          selectionSet: '{ id }',
          fieldName: 'getUser',
          args: ({ id }) => ({ id }),
        },
      },
    },
    // Even though localSchema is placed last in the array
    {
      schema: localSchema,
      merge: {
        User: {
          selectionSet: '{ id }',
          fieldName: 'getUserById', // The fieldName is DIFFERENT so it won't work
          args: ({ id }) => ({ id }),
        },
      },
    },
  ],
});

[tichopad]

UPDATE: The above only works for User type returned by the top-level getUserById query. If there are other queries returning User, it doesn't apply.

[tichopad]

The setup above will work for fields unique to localSchema, but it looks like I have to stub every query that returns User in localSchema to make the override work.