Unlocking Insights: Navigating the World of GraphQL Observability
summary
Claim: GraphQL observability needs path-based analytics that break each operation into field-level paths and store one row per request with counts, object return sizes and timings so teams can spot overfetching, hot resolvers and schema coverage without full traces. Use OTLP traces selectively because per-resolver spans explode cost. Implement typed error results (UserResult with an errors list), tag schema fields for severity, and surface a schema coverage view plus per-client filters and alerts.
AI-written summary · about
chapters (6)
- 0:00Introduction to observability
- 1:55Key observability questions
- 6:46Pillars of observability
- 10:20Path-based analytics
- 16:02Managing errors in GraphQL
- 22:22Conclusion and Q&A
related talks
52mGraphQL Observability with Elastic and OpenTelemetry
23mGraphQL Observability
08mGraphQL Observability
26mBeyond HTTP 200: Observability With GraphQL
18mWhat Could Go Wrong with a GraphQL Query and Can OpenTelemetry Help?
32mWhat Could Go Wrong with a GraphQL Query & Can OpenTelemetry Help?
17mUnlocking Observability with React & Node.js
21m200 NOT OK: High-Resolution Observability