Reputation: 311
I am trying to build a custom Apollo extension to capture some performance metrics (duration of execution) of resolvers and logging them to an APM tool. From the Apollo documentation, Github issue here and an example published by Apollo, I found that the method willResolveField
when overridden, receives GraphQLResolveInfo
(which in turn has the parent type parentType
and field name fieldName
). If one can notice, the fields are already resolved when this method is called by the Apollo server. Does someone know where this field resolution actually takes place before sending it to willResolveField
?
On the other note, unless my understanding is wrong - the name willResolveField
seems to be quite misleading. Can someone kindly shed some light on this?
Sample code of what I'm trying to achieve
class GraphQLAPMExtension implements GraphQLExtension<TContext> {
requestDidStart(options:{ request, operationName, ... }) {
// perform APM specifics to log the request and other info
return (...errors) => {
if(errors.length) {
// some more custom APM stuff!
}
}
}
willResolveField(source, args, context: TContext, info: GraphQLResolveInfo) {
// info contains parentType and fieldName
// and it seems to be that fields are already resolved and passed to this function
}
}
Upvotes: 2
Views: 726
Reputation: 84837
There is already an extension for tracing requests that's built into ApolloServer. The source code can be found here. It sounds like you could just fork that.
Upvotes: 0
Reputation: 311
After some amount of digging into the graphql
package. It is looking like the function resolveFieldValueOrError
does the resolution. It can be found under the ./execution
section. Looks like I will have to fork the graphQl project and make the modifications that I wish.
Another, more practical direction, was to trace the Apollo server creation's tracing parameter. After some quick digging, found that it is using the apollo-engine-reporting
package.
Upvotes: 1