@envelop/opentelemetry and @opentelemetry/instrumentation-graphql

[mannyluvstacos]

Hi @dotansimha and community!

I am Manny! (@mannyluvstacos on twitter) 👋🏽🤝

I finished reading Introducing Envelop - The GraphQL Plugin System and that led me toward the Plugin Hub with my focus going immediately to @envelop/opentelemetry! (🎉 yay!)

It is great that this plugin is being provided to provide OpenTelemetry access to developers using Envelop!

I am curious to better understand how @envelop/opentelemtry and where it may be useful in comparison to using @opentelemetry/instrumentation-graphql and passing that instrumentation along in the configuration of the TracerProvider.

They appear to be unlocking the same basic features,

• create spans for GraphQL Operations
• parse and separate spans into
  -- parse
  -- validate
  -- execute

Are there additional benefits to using @envelop/opentelemetry that I am not seeing?
I currently am exploring Envelop and so I have not fully wrapped my head around this paradigm.
I would love to hear your thoughts on this and learn more!

Recently at work completed wiring in OpenTelemetry using @opentelemetry/node and the related packages (one of those being the GraphQL Instrumentation) to provide traces to our OTel collector and so in seeing this Envelop Plugin, I am curious what benefits there may be to going with this approach.

Look forward to our discussion!

[dotansimha]

Hi @mannyluvstacos , thank you for starting this discussion, this is super interesting :)

The main reasons we chose to create a new plugin for envelop and not using @opentelemetry/instrumentation-graphql:

1. We started envelop with a modern stack, and wanted to offer ESM modules since this is the direction the NodeJS ecosystem took. Instrumentation doesn't work at the moment with ESM (Question: Plans for Node.js ESM Module Support? open-telemetry/opentelemetry-js#1946 , instrumentation-graphql not working for ESM modules open-telemetry/opentelemetry-js-contrib#535)
2. envelop is looking to offer more than just instrumentation - the plugin has the potential to allow more flexibility and provide a tailor-made approach (for example, we might want to allow tracing of envelop plugins execution time).
3. We are looking for ways to allow plugins to enrich the runtime of other plugins. In that context, think of report cache hit/miss to OTel, report metadata based on plugins (for example, if a specific execution of a GraphQL operation usually takes 1s, but with caching it takes 0.01s, we can add metadata for the reported data, and indicate that we had a cache hit).
4. Instrumenting GraphQL is tricky, and OTel collector automatically wraps and changes the schema, and not just wraps functions (because it replaces the schema resolvers). In many cases, it causes an overhead of performance (even just 0.5ms per resolver, in large queries, might sums up). In envelop plugin we allow developers to choose what to trace, and resolvers tracing is opt-in.

Also, personally, I'm not a big fan of monkey-patching and instrumentation process that changes modules / files under node_modules. But that's only my personal opinion here, and maybe you'll convince me otherwise :D looking forward for your response!