Transform resolved fields in top-level query before responding

[kdaniel21]

Hey!

First of all, I really appreciate your work with this library, and I also appreciate that I can ask here knowing that you'll likely help out, even if it's not strictly a bug/feature request. :)

I'm facing a situation where I need a "lookahead" functionality, which I can use to transform the the final object before returning. Consider the following query:

query {
  limitations {
    fooLimitation(id: ID!)
      currentCount
    }
    barLimitation(id: ID!) {
      currentCount
    }
  }
}

To resolve currentCount in each nested field, I have to take two steps: first, query the resource with the id ID, and then pass down the retrieved value to another function, and query the DB again.

As you might see, with batching, I could decrease the n*2 complexity (n = the number of fooLimitations, barLimitations etc. fields) to a complexity of 2, by querying the database once for the first step, and once for the second step, regardless of the number of nested fields.

Combining the queries here is not the hard part as in the implementation I can just return a BatchQuery<BatchQuery<number>>. Hence, if I could get access to the entire object in the limitations query before resolving/responding (with all the fields being resolved), I could just run it through twice a batch query resolver, which would basically unwrap the BatchQuery<BatchQuery<number>> to a simple number, and return the unwrapped object.

At first, I was fairly certain that I can simply achieve this with a traditional middleware, yet, no success. I also tried graphql-middleware, and Apollo Server's willSendResponse as well. For the former, the nested fields weren't resolved yet, so it was useless for this use case (and it was really similar to the type-graphql's middlewares). For the latter, at the point it reached the hook, the GraphQL validation had already failed (expected Float, received a BatchQuery object). I also tried digging up the GH issues of this library and other similar libraries too, but for some reason, I haven't come across any similar feature request/question (so I'm not ruling out that simply I'm missing something).

The closest I got was basically writing an own helper function that uses the info object to determine which fields were requested, and call those fields' resolver function manually, while passing in the appropriate parameters by hand. Still, I wouldn't be a big fan of this as it'd be rather hacky (especially to always grab the correct arguments), and it'd kind of feel like beating the point of using GraphQL.

I've used DataLoader in the past, still, I haven't managed to come up with a plan to twist it in a way that actually goes beyond just resolving a bunch of objects there for "simple" keys.

I really wonder whether you have any idea in mind that would neatly solve this problem. I hope that my description was clear, even though I didn't create a sandbox. If you've got any further questions, I'd be glad to answer them, or also come up with a simple reproduction. Thanks for taking the time!

[kdaniel21]

After stepping back a little bit from the problem, I started looking into DataLoader again. Initially, I wanted to create some custom implementation for the batching based on theirs. Yet, I realized that it is not needed, I can simply use data loader with caching disabled.

Hence, I ended up solving the problem by just adding a graphqlBatchQueryResolver to the context, that combines BatchQueryExecutor (the class responsible for executing the BatchQuerys) and DataLoader. It simply calls dataLoader.load/loadMany, and initializes a DataLoader instance with (queries: BatchQuery[]) => this.batchQueryExecutor.executeQueries(queries), and disables caching. I can simply call graphqlBatchQueryExecutor in the nested field resolvers, and they are batched exactly as I wanted.

I hope it will be useful for somebody in the future, even if their problem domain is slightly different. But feel free to drop a comment here, I might be able to help!