What Could Go Wrong with a GraphQL Query & Can OpenTelemetry Help?
summary
A Node.js Express travel API stitches a GraphQL gateway to a GraphQL country service plus REST image and weather backends and uses OpenTelemetry + Jaeger + Prometheus to get end to end traces and RED metrics. Distributed traces surface a sudden 25% error rate and show resolver errors that still return HTTP 200 unless a custom graphql_error_message span attribute is added. Traces reveal an N+1 pathology with 27 outgoing HTTP requests per query and P95 alone proves too coarse.
AI-written summary · about
chapters (15)
- 0:00Introduction to the talk
- 1:05Why operationalizing GraphQL matters
- 3:10GraphQL setup in a travel app
- 6:58What is OpenTelemetry
- 9:26OpenTelemetry components
- 10:30Adding OpenTelemetry to GraphQL
- 13:16Common GraphQL errors
- 15:26Resolver-level errors in GraphQL
- 18:17GraphQL performance issues
- 22:15Solving N+1 query problems
- 23:18Summary and resources
- 24:20Q&A on tracing costs
- 27:11Q&A on logging strategies
- 28:15Q&A on authorization delays
- 29:54Q&A on troubleshooting with traces
related talks
18mWhat Could Go Wrong with a GraphQL Query and Can OpenTelemetry Help?
26mBeyond HTTP 200: Observability With GraphQL
52mGraphQL Observability with Elastic and OpenTelemetry
08mGraphQL Observability
25mUnlocking Insights: Navigating the World of GraphQL Observability
23mGraphQL Observability
33mBad API Observability
21m200 NOT OK: High-Resolution Observability