This plugin adds hooks for tracing and logging resolver invocations. It also comes with a few
additional packages for integrating with various tracing providers including opentelemetry, New
Relic and Sentry.
The Tracing plugin is designed to have very limited overhead, and uses a modular approach to cover a
wide variety of use cases.
The tracing plugin comes with a number of utility functions for implementing common patterns, and a
couple of provider specific modules that can be installed separately (described in more detail
below).
The primary interface to the tracing plugin consists of 3 parts:
A new tracing option is added to each field, for enabling or configuring tracing for that field
The tracing.default which is used as a fallback for any field that does not explicitly set its
tracing options.
The tracing.wrap function, which takes a resolver, the tracing option for a field, and a field
configuration object, and should return a wrapped/traced version of the resolver.
For more advanced tracing setups, you may want to allow fields to provide additional tracing
options. You can do this by customizing the Tracing generic in the builder.
In most applications you won't want to configure tracing for each field. Instead you can use the
tracing.default to enable tracing for specific types of fields.
There are a number of utility functions for detecting certain types of fields. For most applications
tracing every resolver will add significant overhead with very little benefit. The following
utilities exported by the tracing plugin can be used to determine which fields should have tracing
enabled by default.
isRootField: Returns true for fields of the Query, Mutation, and Subscription types
isScalarField: Returns true for fields that return Scalars, or lists of scalars
isEnumField: Returns true for fields that return an Enum or list of Enums
isExposedField: Returns true for fields defined with the t.expose* field builder methods, or
fields that use the defaultFieldResolver.
Tracers work by wrapping the execution of resolver calls. The tracing.wrap function keeps this
process as minimal as possible by simply providing the resolver for a field, and expecting a wrapped
version of the resolver to be returned. Resolvers can throw errors or return promises, and correctly
handling these edge cases can be a little complicated so the tracing plugin also comes with some
helpers utilities to simplify this process.
tracing.wrap takes 3 arguments:
resolver: the resolver for a field
options: the tracing options for the field (set either on the field, or returned by
tracing.default).
fieldConfig: A config object that describes the field being wrapped
The wrapResolver utility takes a resolver, and a onEnd callback, and returns a wrapped version
of the resolver that will call the callback with an error (or null) and the duration the resolver
took to complete.
The runFunction helper is similar, but rather than wrapping a resolver, will immediately execute a
function with no arguments. This can be useful for more complex use cases where you need access to
other resolver arguments, or want to add your own logic before the resolver begins executing.
When defining tracing options for a field, you may want to pass some resolver args to your tracing
logic.
The follow example shows how arguments might be passed to a tracer to be attached to a span:
The default option can also return a function to access resolver arguments:
It is important to know that if a field uses a function to return its tracing option (either
directly on the field definition, or as a default) the behavior of the wrap function changes
slightly.
By default wrap is called for each field when the schema is built. For fields that return their
tracing option via a function, wrap will be called whenever the field is executed because the
tracing options are dependent on the resolver arguments.
For many uses cases this does not add a lot of overhead, but as a rule of thumb, it is always more
efficient to use tracing options that don't depend on the resolver value.
The above example could be re-designed slightly to improve tracing performance:
The tracing plugin for Pothos only adds spans for resolvers. You may also want to capture additional
information about other parts of the graphql execution process.
This example uses GraphQL Yoga, by providing a custom envelop plugin that wraps the execution phase.
Many graphql server implementations have ways to wrap or replace the execution call, but will look
slightly different.
Envelop also provides its own opentelemetry plugin which can be used instead of a custom plugin like
the one shown above. The biggest drawback to this is the current version of @envelop/opentelemetry
does not track the parent/child relations of spans it creates.
The following setup creates a very simple opentelemetry tracer that will log spans to the console.
Real applications will need to define exporters that match the opentelemetry backend you are using.
Datadog supports opentelemetry. To report traces to datadog, you will need to instrument your
application with an opentelemetry tracer, and configure your datadog agent to collect open telemetry
traces.
The tracing plugin for Pothos only adds spans for resolvers. You may also want to capture additional
information about other parts of the graphql execution process.
This example uses GraphQL Yoga, by providing a custom envelop plugin that wraps the execution phase.
Many graphql server implementations have ways to wrap or replace the execution call, but will look
slightly different.
The tracing plugin for Pothos only adds spans for resolvers. You may also want to capture additional
information about other parts of the graphql execution process.
This example uses GraphQL Yoga, by providing a custom envelop plugin that wraps the execution phase.
Many graphql server implementations have ways to wrap or replace the execution call, but will look
slightly different.
The tracing plugin for Pothos only adds spans for resolvers. You may also want to capture additional
information about other parts of the graphql execution process.
This example uses GraphQL Yoga, by providing a custom envelop plugin that wraps the execution phase.
Many graphql server implementations have ways to wrap or replace the execution call, but will look
slightly different.