GraphQL Apollo Server

[hekike]

Is your plugin request related to a problem? Please describe.
GraphQL batches multiple queries and entities as a data access protocol into a single HTTP request.
In the background, the GraphQL server will run multiple so-called resolvers that return data for a specific chunk of the graph to fulfill these GraphQL queries. Resolvers can run parallel and depend on each other while they usually fetch data from downstream services or from databases using data-loader concept which makes the data orchestration even more complex. Understanding this execution with timing and error is crucial to debug and optimize GraphQL servers.

Apollo Server is probably the most popular library to run GraphQL in production.

Commercial alternative for GraphQL Apollo Tracing
https://blog.apollographql.com/the-new-trace-view-in-apollo-engine-566b25bdfdb0

Is it applicable for Node or Browser or both
Node.js only.

Do you expect this plugin to be commonly used
Yes
Weekly Downloads: don't know the exact number

Additional context

• GraphQL Tracing format could may solve this in a more general way and provide compatibility for all GraphQL engines: https://github.com/apollographql/apollo-tracing

[hekike]

Here is a PoC with using the Apollo Server extensions interface: https://github.com/open-telemetry/opentelemetry-js/compare/master...hekike:feat/plugin-apollo-server?expand=1

[dyladan]

According to npm, the apollo module receives ~250k downloads weekly.

@hekike if a request comes in on http, and apollo looks into a couple data stores (say mysql, a http api, and a mongodb) then isn't it sufficient to instrument the underlying transports? What value is gained in this case from instrumenting apollo directly?

[hekike]

The mapping between GraphQL resolvers and data sources like MongoDB won't be 1:1 mapping.
GraphQL will run a resolver for every index, for example, it will also skip resolvers when the parent over fetches from data source. Also usually people put the dataloader layer between resolvers and data sources so batching and caching will make an even bigger disconnect between resolver dependencies, errors and latencies between resolver and data sources. For example, 10 resolvers will maybe cause one partial HTTP request. In some organizations, this separation also reflects in team structures and data source clients are provided by other teams than teams who work on resolvers. Personally I see a value in tracking GraphQL orchestration/resolver in tracing.

[wtgtybhertgeghgtwtg]

With a few nits, the PoC looks good. Is there anything I can do to help move it along?

[dyladan]

We're trying to move away from hosting all possible plugins in this repo. In the future we plan to have a contrib style repo where plugins may live, but for now you may be better off self-hosting your plugin and adding it to the registry at https://opentelemetry.io/registry/.

[vmarchaud]

I'm moving the issue on the contrib repository, if someone has a implementation feel free to open up a PR over there so we can merge it !

[jon-whit]

What's the status on this effort? I'm also looking at integrating OpenTelemetry into a GraphQL implementation using apollo-server.

[dyladan]

As far as I'm aware, nobody is working on this right now

[obecny]

@jon-whit are you working on that ?

[obecny]

ok it looks like no1 is working on that, I'm taking over it

[hongbo-miao]

Hi @obecny just a suggestion, it would be great to support from GraphQL.js level, so it does not matter which GraphQL framework people are using. 😀

[obecny]

@hongbo-miao yes that's exactly what will be doing

[jon-whit]

@obecny how's this work coming along? Anything that I can help with? My team and I are looking to expedite this process a bit. We really would love to have this.

[obecny]

@jon-whit in progress (graphql first), FYI to be able to patch graphql I had to refactor plugin instrumentation too which was done, without this such plugin could not be done.