Accessing all GraphQLResolveInfo objects in batch executor

[maxbol]

Hi!

As per https://github.com/ardatan/graphql-tools/blob/master/packages/batch-execute/src/mergeRequests.ts#L107 , context and info for a batch request are always equal to the context and info parameters for the first request in the array.

Is there someway to circumvent this limitation to access the full array of info objects for all original requests in the batch execution, without forking and extending graphql-tools itself?

Cheers,
Max

[ardatan]

@maxbol
Hi!
It seems like currently we don't have this feature but instead of forking if you'd like to create a PR in here, we would love to merge and release :)

[yaacovCR]

Can you share more of the use case? Context is usually identical. Info is an optional request property that in our usual use case will go unused in batch execution….

But I suppose your use case differs.

prs always welcome

[maxbol]

Thank you both for responding so swiftly as per usual :)

This old discussion pretty much sums up my use case: #2946 (reply in thread)

First of all, I'd love to submit a PR for this, but the truth is I'm not completely sure what the most desirable change in behavior with regards to mergeRequests would even be. So I'll try to detail my problem as best I can, and open up for discussion of what the most optimal solution would be.

In my services, I am attaching request state to a map based on original request ID + resolver path. The latter is applied recursively, so a resolver on myQuery.0.myField can retrieve state for myQuery.0 or myQuery, but not myQuery.1 etc. Therefore, resolvers need to be made cognizant of their exact location in the super-query (gateway query).

To accomplish this, I am passing the path along from the gateway as a header, that is then appended to the context of the subquery service (as detailed in the discussion above). I'm only just now realizing the issues this is causing for batched requests. For instance, a state setter on the type extension resolver (sub query) corresponding to myQuery.X will be setting each iteration's state to the same path (myQuery.0) because of the way that request merging works. Getters on myQuery.X.myField will all be retrieving state from myQuery.0.myField, and then myQuery.0 etc (or sometimes myQuery.1.myField etc depending on resolution order).

To use a (simplified) real world example:

query StartingpointQuery {
   usersByIds(ids:[1,2]) { # service "identity"
      policies { # service "policies"
         queries {
            startingpointQuery{
               _userId
               _policyId
               _user { # service "identity", private field, sets state with the tag "user"
                  name
               }
               children(type:"MODEL"){ # external service "cce"
                  _user { # service "identity", private field, retrieves state with tag "user"
                     name
                  }
               }
            }
         }
      }
   }
}

In the example above, the STARTING_POINT_QUERY type defined in the external cce schema is hijacked by the policies service and then effectively extended by the external schema. Thus we can inject all manner of context-based fields into it (such as _user above), as well as use the values of those fields to populate variables for the request to the external service. However, there is simply no field on the STARTING_POINT_LEVEL type returned by children (owned by the external schema) that gives us any information of which user context we are currently operating under. To accomplish that, we need to make the subservices stateful on the level of a gateway request.

(I'd like to acknowledge that making tree resolution stateful in this way is kind of antithetical to GraphQL philosophy. However, it seems to be the only possible solution for our specific case (integrating an external GraphQL schema into our set of managed services). And yes, the real world application has a lot more of this exact situation, in even more complex ways.

The way I see it, there are two separate issues at work. The first is on the level of key-batching, and the second on the level of query-batching (request merging). The key batching issues can be easily solved by simply turning off key batching for fields that either set or get request state. This leaves us with a simple batched request like:

query ($graphqlTools0__v0_key: Key!, $graphqlTools1__v0_key: Key!) {
  graphqlTools0___typename: __typename
  graphqlTools0__userStartingpointQuery: _userStartingpointQuery(key: $graphqlTools0__v0_key) {
    __typename
     _user {
      __typename
      name
    }
  }
  graphqlTools1___typename: __typename
  graphqlTools1__userStartingpointQuery: _userStartingpointQuery(key: $graphqlTools1__v0_key) {
    __typename
     _user {
      __typename
      name
    }
  }
}

Essentially, what would solve my problems would be if there was some way to include the path of the original request into the key scalar of the sub query itself. Alternatively, a way to access things like the info object of the original request through the additionalArgs directive.

[yaacovCR]

I didn’t quite get everything I’m afraid. Why does the subservice need the path exactly? What does it do with it?

In general, What I should’ve said with regard to the original discussion is that if you were combining local Schema’s, you’re probably better off with schema merging or graphql modules and if you were combining remote schemas you can accomplish something similar to the above with Schema stitching, which works with remote schemas.

Maybe an end to end example might help me. Maybe @ardatan or @gmac have more thoughts or better insight

[gmac]

I’d need to see a working example to understand all of what you’re saying, but the parts that sound most relevant about your scenario is that you’re combining local and remote schemas? If so, Stitching sounds like the tool you’re after. Batch execution is a much more primitive tool, useful for combining many requests bound to the same place (and to @yaacovCR’s point, all those requests would share GraphQL context). Your concerns about managing paths sounds a lot like what Stitching does, and it’s responsibilities are very much a superset of batch execution.

[maxbol]

Hi,

To be clear, we are happily using schema stitching already. :) But as far as I understand, @graphql-tools/stitch is dependent on @graphql-tools/batch-execute through its use of @graphql-tools/delegate, no?

Also, we are using 100% remote subschemas. As well as a central gateway that loads schemas from a github based schema registry (so we are using stitching directives). The distinction I'm making is not between remote and local subschemas, but rather between schemas that are managed through our registry and whose development is part of our project, and the one schema that is not. For the latter, I've written a merge config that is part of our gateway code. All of this works just fine! The only reason I mentioned it was to explain why we needed to be able to handle state in the way we do. So for the purposes of this conversation, all we need to know is that we are using only remote subschemas.

To hopefully clarify our use case somewhat:

Our services are stateful on the level of a gateway request. What I mean by that is that graphql contexts are instantiated with a state store created or loaded by using the original request ID as a key. So every sub query to service X triggered by the gateway request will all have access to a common state. So far, so good, but this state also needs to be hierarchical. So if I write to the state in the resolvers of one generation of sub-queries (myQuery.X), these values should only affect resolvers further down that tree. Ie myQuery.0 affects myQuery.0.myField but not myQuery.1.myField etc.

I no longer believe the best way to solve this is through the use of headers (since once we hit the executor we'll already have batched the request in various ways), but rather would like to figure out a way to roll the path into the keys of the sub query.

I wrote this simple little subschema transformation and applied it to all my subschemas (in the gateway):

export class QueryPathTransform implements Transform {
    public transformSchema(originalWrappingSchema: GraphQLSchema): GraphQLSchema {
        const types = originalWrappingSchema.getTypeMap();

        let schema: GraphQLSchema = originalWrappingSchema;

        for (const key of Object.keys(types)) {
            const type = types[key];

            if (type.astNode?.kind !== 'ObjectTypeDefinition') {
                continue;
            }

            schema = appendObjectFields(schema, type.name, {
                _queryPath: {
                    resolve: (_: any, __: any, ___:any, info: GraphQLResolveInfo) => {
                        return queryPath(info.path.prev ?? { key: '', prev: undefined }) // Turns info.path into an object-path like string
                    },
                    type: new GraphQLNonNull(GraphQLString)
                }
            });
        }

        return schema;
    }   
}

This successfully added _queryPath as a field on all object types in all remote subschemas.

When querying it, we got the expected path values across all subschemas:

query{
  usersByIds(userIds:[1,2]){
    name
    _queryPath
    policies{
      _queryPath
      policy{
        _queryPath
        name
      }
      queries{
        startingpointQuery(priceConfigIn:{name:"default",variableReferences:[]}){
          availableChildren
          _queryPath
        }
      }
    }
  }
}

{
  "data": {
    "usersByIds": [
      {
        "name": "Henrik Johannesson",
        "_queryPath": "usersByIds.0",
        "policies": [
          {
            "_queryPath": "usersByIds.0.policies.0",
            "policy": {
              "_queryPath": "usersByIds.0.policies.0.policy",
              "name": "Employees"
            },
            "queries": {
              "startingpointQuery": {
                "availableChildren": [],
                "_queryPath": "usersByIds.0.policies.0.queries.startingpointQuery"
              }
            }
          }
        ]
      },
      {
        "name": "Carl Pihl",
        "_queryPath": "usersByIds.1",
        "policies": [
          {
            "_queryPath": "usersByIds.1.policies.0",
            "policy": {
              "_queryPath": "usersByIds.1.policies.0.policy",
              "name": "Employees"
            },
            "queries": {
              "startingpointQuery": {
                "availableChildren": [],
                "_queryPath": "usersByIds.1.policies.0.queries.startingpointQuery"
              }
            }
          }
        ]
      }
    ]
  }
}

However when I added _queryPath to the selectionSets of our @key directives in the identity service:

type STARTING_POINT_QUERY @key(selectionSet: "{ _companyId _userId _queryPath }") {
  _marketLocale: String!
  _user: User
  _userId: Int
}

..._queryPath was simply missing from the original execution result when logged in the key generator function.

After reading on it a bit, I assume (but correct me if I'm wrong) that the stitcher interfaces with the untransformed subschemas when handling type merging/delegating subqueries?

I also tried playing around with result transformations to inject the query path that way, only to realize that the info object accessible through transformResult will be identical to that passed to the batch executor. Clearly this is not the way to go.

Is there some neat way to implement a field on the gateway level like this, that can then be depended upon by remote subschema services? Alternatively, any other way to include a value like that in all keys before the request is sent to the executor?