Schema merge via array field?

[gmac]

@yaacovCR just got really looking at schema merging for the first time... it's super impressive looking, and actually looks like a pretty comprehensive alternative to federation that might even have some advantages for us.

That said, I keep coming back to the use of single-record queries here for handling the service crossover (ie: userById)...

{
  schema: chirpSchema,
  merge: {
    User: {
      fieldName: 'userById',
      args: (originalResult) => ({ id: originalResult.id }),
      selectionSet: '{ id }',
    },
  },
},

How is this optimized for accessing collections of records one at a time? I assume their must be some kind of batching under the hood? Even then, it would seem like that turns into a massive query if you batch a large selectionSet over and over again for multiple single record requests... is it possible to do this crossover using a list endpoint that requests a collection of IDs from a service and returns an array (ie: usersByIds(ids: [ID]): [User])...? Seems like exchanging arrays would be more efficient.

Looking forward to playing around with this more.

[yaacovCR]

Recent addition, also needs docs

#1735

[gmac]

So is this comment still accurate?

#1710 (comment)

Specifying a “key” function will switch into many-mode, at which time the query method is assumed to receive a keys array and return a records array?

[yaacovCR]

Should be!

[yaacovCR]

We may need to customize further, see #1825

[gmac]

Another thought here on configuring the merge schema: it'd be useful if there was an option to merge types without requiring a lookup service in both directions... this is useful for unidirectional associations where lookups would only realistically occur in a single direction. For example:

usersSchema

type User {
  id: ID!
  username: String!
  posts: [Post]!
}
type Post {
  id: ID!
}
type Query {
  users(ids: Int): [User]!
}

postsSchema

type Post {
  id: ID!
  body: String!
  user: User!
}
type User {
  id: ID!
}
type Query {
  posts(ids: Int): [Post]!
}

gatewaySchema

const gatewaySchema = stitchSchemas({
  subschemas: [
    {
      schema: usersSchema,
      merge: {
        Post: true,
        User: {
          fieldName: 'users',
          selectionSet: '{ id }',
          key: ({ id }) => id,
          args: (ids) => ({ ids }),
        },
      }
    },
    {
      schema: postsSchema,
      merge: {
        Post: {
          fieldName: 'posts',
          selectionSet: '{ id }',
          key: ({ id }) => id,
          args: (ids) => ({ ids }),
        },
        User: true,
      }
    },
  ],
  mergeTypes: true,
});

In this setup, we can use id-only models to declare associations with models in other services, which is super nice (and replaces the need for schema extensions with stitching resolvers). However, those ID-only models are really just ID stubs; they have no other data so the gateway will never have a reason to perform a lookup on them (all lookups will go to the service with additional model data). All that said, it's less than ideal that we'd need to setup a dedicated query method for an id-only stub simply to activate schema merging on the model. It'd be nice if a service could activate schema merging for a type without requiring a query for it.

[yaacovCR]

I think it would be pretty straightforward to enable this, I just previously did not see the use case. I think it would be technically easier to allow merging from different schemas without both directions of lookups even if it didn't make sense, and just buyer beware, rather than limiting it to this exact use case.

Otherwise, the set of cases in which it seems to be legal would be when the available fields include just the fields in the selectionSet defining the key, whether it be single or multiple...

[gmac]

RE:

Otherwise, the set of cases in which it seems to be legal would be when the available fields include just the fields in the selectionSet defining the key, whether it be single or multiple...

Yep, that's correct. When a service contains no data but the key, then it should be considered a unidirectional service. Right now it feels like a bit of an anti-pattern that a lookup service is required in both directions to enable merging, forcing you to fake some kind of non-service for a unidirectional implementation. Just having a default that raises an error would be sufficient. In my experimenting so far, I've been toying with this kind of hack implementation:

{
  schema: postsSchema,
  merge: {
    Post: {
      fieldName: 'posts',
      selectionSet: '{ id }',
      key: ({ id }) => id,
      args: (ids) => ({ ids }),
    },
    User: {
      fieldName: '__unimplemented__',
      selectionSet: '{ id }',
      args: (ids) => throw new Error('cannot fetch User data from posts service.'),
    }
  }
}

[yaacovCR]

I think you should create a bonafide issue with a feature request for this to track

[gmac]

#1839

[gmac]

Related to the original question, would there be a way to perform this sort of linkage going through an array method (ie: _productsByUpcs)? https://github.com/ardatan/graphql-tools/blob/master/packages/batch-delegate/tests/typeMerging.example.test.ts#L233-L235

Product: {
  selectionSet: '{ upc weight price }',
  fieldName: '_productByUpc',
  args: ({ upc, weight, price }) => ({ upc, weight, price }),
}

Federation uses that idea where the stub representations would be sent to the subservice to be transformed into a list of models. Could that same sort of pattern be achieved? Maybe something like this...?

Product: {
  selectionSet: '{ upc weight price }',
  fieldName: '_productsByUpcs',
  key: ({ upc, weight, price }) => ({ upc, weight, price }),
  args: (keys) => ({ representations: keys }),
}

While it seems like that works for getting the data over to the subservice, how is the returned data merged in the gateway? Are all three fields used as the key? As long as one field contains a real unique ID, I suppose it wouldn't matter if the other two fields contain collisions. Is that accurate?

[yaacovCR]

I think you would use the dataloader options for this?

[gmac]

Could you please link to a test that demonstrates dataloader options? I'm still unclear on what/how this feature works on its own (although I assume that type merging is wrapping it?) It appears that type merging is making a whole lot of batching operations invisible, no?

[yaacovCR]

See:

https://www.graphql-tools.com/docs/schema-stitching#batch-delegation
https://github.com/ardatan/graphql-tools/blob/master/packages/batch-delegate/tests/basic.example.test.ts

[yaacovCR]

And yes, aim of MergedTypeConfig properties is to allow you to customize the merging resolver, but also to write one for you with via specifying a few common properties, with versions for both simple and batch delegation.