Is there a way to batch/combine field resolvers?

[kaysond]

First I have a background question: are field resolvers how type-graphql implements what Apollo Server calls resolver chains? This seems to be the case, but the example is somewhat trivial (calculating the averageRating) so I just wanted to make sure it would also work for fetching entire objects. And then the @Root() decorator is what passes the parent?

Assuming all that is correct, here is my situation. I have a schema that looks something like:

type Query {
    getJobs: [Job!]
}

type Job {
    id: ID!
    queue: String!
    command: String!
    cwd: String!
    resources: String!
}

The resolvers get the data from a command line API that has two limits: commands per minute, and payload (in bytes) per minute. Right now, the getJobs resolver runs a command like cli-tool -o 'id queue command cwd'. This is bad for the second limit, because even if the submitted query only wants one or two of the fields (which is what usually happens), I'm still fetching the entire payload. I do cache everything, but I'm running up against the limits.

So what I could do is create a field resolver for every field. This would allow me to only fetch data I actually need (i.e. cli-tool -o 'command'), but then I would be executing a command for every field, hitting the other API limit.

What I really need is some way to know which particular fields are requested, so I can only run the cli-tool with those arguments. graphql has dataloader but I don't want to batch across time. I've seen some info online about a GraphQLRequestContext. Does type-graphql have this and expose it to the resolver in any way? Any other way I could do this with type-graphql?

[MichalLytek]

are field resolvers how type-graphql implements what Apollo Server calls resolver chains?

It's a standard GraphQL concept, not an Apollo feature.

I'm still fetching the entire payload

You need something like #10, to know before fetching the data which fields are requested.
But have in mind that it's dangerous because other field resolvers now can't expect all the fields to be present in @Root().

[kaysond]

Thanks that's exactly what I was looking for!