GraphQL: Smooth Schemas and Rough Edges
summary
Practical account of moving New Relic from REST to GraphQL: claims about fewer round trips and partial responses are demonstrated using graphql-java on the JVM, Dropwizard for HTTP, a schema‑first workflow that generates Java types, and a custom gateway called NerdGraph that uses schema stitching to compose many teams’ schemas. Monitoring requires naming transactions, tracing data fetchers, and surfacing GraphQL errors so you can detect failing nodes; the architecture scales across dozens of teams and proves viable in production.
AI-written summary · about
chapters (15)
- 0:00Start
- 6:46What does it look like?
- 9:07Now what?
- 11:58And when something goes wrong?
- 13:34Why did we choose it?
- 18:01Implementing a GraphQL API
- 31:23Distributed GraphQL architectures
- 33:03Federation vs. Schema stitching
- 39:16Monitoring ...gets more complicated
- 42:29And don't forget about errors
- 43:29Learnings and takeaways
- 43:41Understand the trade-offs
- 44:21Don't give up on monitoring
- 44:45Design your schema carefully
- 45:42Embrace error handling
