Stitching selectionSet with input variables?

[gmac]

I'm trying to send field arguments with a stitching query fragment – is this possible? I'm still on GraphQL Tools 5. For example:

Remote schema

type EntrySet {
  recentEntryIds(pageNumber: Int=1):[ID!]!
}

Extended schema

extend type EntrySet {
  recentEntries(pageNumber: Int=1):[Entry!]!
}

Stitching resolver

export default {
  EntrySet: {
    recentEntries: {
      selectionSet: `{ recentEntryIds(pageNumber: $pageNumber) }`,
      resolve: async (obj, args, context, info) => {
        // delegate returned IDs to remote schema that stitches Entry ...
      }
    }
  }
};

This fails with Variable "$pageNumber" is not defined.. Is there a different syntax that should be used to passthrough variables, or another configuration that needs to be enabled? Looks like there's something called AddArgumentsAsVariables being setup within schema delegation, but I don't see what it's doing. Thanks!

[gmac]

I reached out to GraphQL Tools support and @ardatan replied, "Unfortunately it is not possible".

[gmac]

(he followed up with "...but that doesn't mean it is not possible to implement it. We can discuss it on GitHub.")

[ardatan]

@yaacovCR What do you think?

[gmac]

Would it be possible to simply allow the fragment option (which I think is now called selectionSet in GQT v6?) to be defined as a function that returns a string? If the selection set could be evaluated dynamically based on the current request, that would be sufficient.

[yaacovCR]

Does the following work?

Extended schema

extend type EntryGroup {
  recentEntries(pageNumber: Int=1):[Entry!]!
}

Stitching resolver

export default {
  EntryGroup: {
    recentEntries: {
      selectionSet: '{ recentEntryIds }',
      resolve: async (group, args, context, info) => {
        return delegateToSchema({
          schema: mySubschema,
          operation: 'query',
          fieldName: 'entries'
          args: {
            ids: group.recentEntryIds,
            pageNumber: args.pageNumber,
          },
          context,
          info,
        })
      }
    }
  }
};

[yaacovCR]

Maybe I don't have the right structure of the subschema -- or understand what you are trying to achieve. Please feel free to elaborate and keep the discussion going.

[gmac]

The issue here is when we need to filter the initial record IDs that get data stitched onto them... For example, say we have Users and Posts:

export default {
  User: {
    posts: {
      selectionSet: '{ postIds }',
      resolve: async (user, args, context, info) => {
        return delegateToSchema({
          schema: 'posts-service',
          operation: 'query',
          fieldName: 'posts'
          args: { ids: user.postIds },
          context,
          info,
        });
      })
    }
  }
};

This looks pretty straightforward – but what if the user has 10K (or more) posts? The initial selection of postIds cannot be optimized for scale. In your proposal above, we're fetching a complete listing of the user's post IDs (which isn't practical at scale), and then handling pagination on the fulfillment side (which also isn't practical). What we really need here is the ability to pass stitched field arguments through in the initial selection set, for example:

Extended schema

extend type User {
  posts(pageNumber: Int=1, perPage: Int=25):[Post!]!
}

Stitching resolver

export default {
  User: {
    posts: {
      selectionSet: '{ postIds(pageNumber:$pageNumber, perPage:$perPage) }',
      resolve: async (user, args, context, info) => {
        return delegateToSchema({
          schema: 'posts-service',
          operation: 'query',
          fieldName: 'posts'
          args: { ids: user.postIds },
          context,
          info,
        });
      })
    }
  }
};

With a pattern like this in place, the initial selection set would be loading pages of IDs (25 at a time), and simply sending those off to the posts service for fulfillment. At present, I've worked around this shortcoming by putting two delegateToSchema calls within my stitching resolver: the first call loads paginated IDs and the second call fulfills them. It'd be far more efficient to have the initial selection set be capable of passing through parameters.

[yaacovCR]

I think this a function to create dynamic additional selection sets with the parameter of the source fieldNode is a great idea, i.e. in your example above the field node for posts would be the parameter and you would have to return postIds, but you would be able to copy the args.

[gmac]

@yaacovCR yep, ideally we'd be able to do something like this:

export default {
  User: {
    posts: {
      selectionSet: (args) => `{ postIds(pageNumber:${args.pageNumber}, perPage:${args.perPage}) }`,
      resolve: async (user, args, context, info) => {
        return delegateToSchema({
          schema: 'posts-service',
          operation: 'query',
          fieldName: 'posts'
          args: { ids: user.postIds },
          context,
          info,
        });
      })
    }
  }
};

[yaacovCR]

I was thinking something a little bit more generic so that you would not just get the arguments but basically the node itself which includes argument nodes, directives, etc and you would return a selection or array of selection nodes, returning a string and then requiring it to be parsed every single time seems less efficient

[yaacovCR]

Does that make sense? Seems kind of wasteful to go from field node to string to new string back to array of selection set nodes, If you choose to do it that way though the option would be open to you with the use of print and parse

[yaacovCR]

For the static selection sets we parse those strings at schema build time

[gmac]

Yep, that makes sense. It doesn’t really matter how the arguments data is formatted as long as there’s an opportunity to customize the field selectionSet with it.

[yaacovCR]

Need to add tests, but may work now from #1766

The latest changes of #1766 are available as alpha in npm: 6.0.13-alpha-63644bdb.0

Quickly update your package.json by running:

npx match-version @graphql-tools 6.0.13-alpha-63644bdb.0

[gmac]

@yaacovCR thanks for the update, just got a chance to try it out... I get a script error at startup as soon as I make selectionSet into a function. I'm running v6.0.14 and this is my first experiment with setting up a resolver:

import { parse } from 'graphql';

export default {
  EntrySet: {
    recentEntries: {
      selectionSet: (field) => {
        console.log(field);
        return parse('{ recentEntryIds }').definitions[0].selectionSet;
      },
      resolve: async (obj, args, context, info) => {
        // ...
      }
    }
  }
};

Note that I've never actually observed this code running because the GraphQL schema stitch fails immediately with the following error:

app_1    | /myapp/node_modules/@graphql-tools/stitch/index.cjs.js:758
app_1    |                     if (!(fieldName in selectionSetsByField[typeName])) {
app_1    |                                     ^
app_1    | 
app_1    | TypeError: Cannot use 'in' operator to search for 'recentEntries' in undefined
app_1    |     at /myapp/dist/stitch/src/stitchingInfo.js:154:36
app_1    |     at Array.forEach (<anonymous>)
app_1    |     at /myapp/dist/stitch/src/stitchingInfo.js:147:27
app_1    |     at Array.forEach (<anonymous>)
app_1    |     at completeStitchingInfo (/myapp/dist/stitch/src/stitchingInfo.js:142:28)
app_1    |     at stitchSchemas (/myapp/dist/stitch/src/stitchSchemas.js:99:21)
app_1    |     at SchemaBuilder.buildInternalSchema (/myapp/src/lib/schema_builder/index.js:45:12)
app_1    |     at Object.<anonymous> (/myapp/src/routes.js:54:38)
app_1    |     at Module._compile (internal/modules/cjs/loader.js:955:30)
app_1    |     at Module._compile (/myapp/node_modules/pirates/lib/index.js:99:24)
app_1    |     at Module._extensions..js (internal/modules/cjs/loader.js:991:10)
app_1    |     at Object.newLoader [as .js] (/myapp/node_modules/pirates/lib/index.js:104:7)
app_1    |     at Module.load (internal/modules/cjs/loader.js:811:32)
app_1    |     at Function.Module._load (internal/modules/cjs/loader.js:723:14)
app_1    |     at Module.require (internal/modules/cjs/loader.js:848:19)
app_1    |     at require (internal/modules/cjs/helpers.js:74:18)
app_1    | [nodemon] app crashed - waiting for file changes before starting...

Am I doing something wrong here? Happy to write up some notes for the doc site once I get it running.

[gmac]

Interestingly, if I add another resolver method to the type before this dynamic selectionSet field, then the error changes:

docs_1   | /myapp/node_modules/@graphql-tools/stitch/index.cjs.js:759
docs_1   |                         dynamicSelectionSetsByField[typeName][fieldName] = [];
docs_1   |                                                                          ^
docs_1   | 
docs_1   | TypeError: Cannot set property 'recentEntries' of undefined
docs_1   |     at /myapp/dist/stitch/src/stitchingInfo.js:155:73
docs_1   |     at Array.forEach (<anonymous>)
docs_1   |     at /myapp/dist/stitch/src/stitchingInfo.js:147:27
docs_1   |     at Array.forEach (<anonymous>)
docs_1   |     at completeStitchingInfo (/myapp/dist/stitch/src/stitchingInfo.js:142:28)
docs_1   |     at stitchSchemas (/myapp/dist/stitch/src/stitchSchemas.js:99:21)
docs_1   |     at SchemaBuilder.buildInternalSchema (/myapp/src/lib/schema_builder/index.js:45:12)
docs_1   |     at SchemaBuilder.buildExternalSchema (/myapp/src/lib/schema_builder/index.js:53:30)
docs_1   |     at Object.<anonymous> (/myapp/docs/lib/index.js:5:68)
docs_1   |     at Module._compile (internal/modules/cjs/loader.js:955:30)
docs_1   | error Command failed with exit code 1.
docs_1   | info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
docs_1   | error Command failed with exit code 1.
docs_1   | info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
docs_1   | [nodemon] app crashed - waiting for file changes before starting...

Based on the observed behavior, it looks like those selectionSetsByField and dynamicSelectionSetsByField dictionaries aren't being created properly in the presence of the opposing field type.

[yaacovCR]

If you get a chance, let me know if this helps. And if you appreciate the effort, please also feel free also to support my open source development by visiting https://github.com/sponsors/yaacovCR

[yaacovCR]

Copy-paste typos sans tests, should be fixed by #1798, still with minimal testing.

The latest changes of #1798 are available as alpha in npm: 6.0.15-alpha-c8ff8c6b.0

Quickly update your package.json by running:

npx match-version @graphql-tools 6.0.15-alpha-c8ff8c6b.0

[gmac]

Awesome, that works! I've now got dynamic arg pass-throughs working using this:

import { parse } from 'graphql';

export function selectionSetWithFieldArgs(selectionSet) {
  selectionSet = JSON.stringify(parse(selectionSet).definitions[0].selectionSet);
  return field => {
    const requestSelectionSet = JSON.parse(selectionSet);
    for (let selectionField of requestSelectionSet.selections) {
      selectionField.arguments = field.arguments.slice();
    }
    return requestSelectionSet;
  };
}

export default {
  EntrySet: {
    recentEntries: {
      selectionSet: selectionSetWithFieldArgs('{ recentEntryIds }'),
      resolve: async (obj, args, context, info) => {
        // ...
      }
    }
  }
};

When I get a chance I'll clean up that selectionSetWithFieldArgs method and submit it as an additional helper for the stitching package. Thanks for your attention here, this is a really good feature.

[gmac]

I've opened a PR for a helper utility method that sets up this arguments passthrough along with supporting docs in #1802.

Thanks for your work on this. Great feature!