Apollo Server GraphQL: Handling of Nested Resolvers

[rr0214]

Apollo server plugin with their GraphQL Apollo Lambda function. Some feedback is that they are seeing 1000+ spans in some cases which are just related to GraphQL stuff all taking less than 1ms. Is there a way to dial back the instrumentation or control it more?

From Michael: "i've been thinking on the problem. i think i'd like to represent each unique resolve path in these situations once and then group the rest into a single segment/span that has attributes representing the individual invocation counts while still capturing individual metrics."

---

Ported from duplicate: https://github.com/newrelic/newrelic-node-apollo-server-plugin/issues/27

https://newrelic.slack.com/archives/G24GM9VRR/p1599855383012600

Setups with nested resolvers can result in resolvers being invoked per item returned at the highest level resolver. For larger datasets, that can result in a ton of data.

At a high level, here are some of the issues that may cause:

• Bloat the amount of data we capture per transaction
• Crowd the UI for transaction traces and DT traces
• Result in high number of broken traces in DT (we only allow 1k spans per minute)
• Other?

After doing some initial research, it seems likely the best approach would be to do some sort of merge of the segments/spans while keeping metrics unique. That being said, there's awkwardness there with starting/ending if there's any sort of repeat.

Other options possible to help with this issue or others, depending on what customer needs come up:

• Filter out list items: do not capture field resolution for items that are a part of a list
  • less ideal, seems like you'd filter out a lot of useful sub-resolvers but depends on the setup
• Filter out paths including wildcards. For example: libraries.books.*
  • Could leverage identical logic to attribute filtering (flatten rules to regex, etc.)
  • High level of flexibility
  • As a primarily solution, could require a ton of configuration. Might not be valuable if merge or similar solution in place
• Once beyond X count group altogether in one span/segment for remainder of list resolver?
  • Avoids awkward start/stop overlap issue
  • Allows for seeing some fine-grained details for items ultimately 'merged'.
  • Possibility of losing fine-grained metric counts unless solve for another way (maybe a way to generate individual metrics when that massive span/segment completes?)
• Other?

Will want to consider impacts to metrics to still allow for best possible tracking down of issues on a per-field resolver basis.

[kmudduluru]

still valid

[workato-integration[bot]]

https://new-relic.atlassian.net/browse/NR-292127