There should be hooks in the implementation such that it would be possible instrument how long queries take.
For example one Ruby implementation
https://rmosolgo.github.io/graphql-ruby/schema/instrumentation#field-instrumentation
uses field wrapping to instrument. This is ok but it requires "opt in" from the schema provider code.
Another way is to have an callback interface that has the beforeFieldResolution() , afterFieldResolution() etc and then have caller insert an implementation of that into the runtime configuration.
The call back would then allow for consumers to use their preferred recording mechanism (JMX, StatsD, DropWizard Metrics etc...)
Another thought is to build a "call graph" of the steps that taken during query resolution and present that back with timings. This might prove too big in practice.
There should be hooks in the implementation such that it would be possible instrument how long queries take.
For example one Ruby implementation
uses field wrapping to instrument. This is ok but it requires "opt in" from the schema provider code.
Another way is to have an callback interface that has the
beforeFieldResolution(),afterFieldResolution()etc and then have caller insert an implementation of that into the runtime configuration.The call back would then allow for consumers to use their preferred recording mechanism (JMX, StatsD, DropWizard Metrics etc...)
Another thought is to build a "call graph" of the steps that taken during query resolution and present that back with timings. This might prove too big in practice.