Monitor, Fix and Deploy (on Friday)
summary
A migration from REST to GraphQL pairs feature flags and a fallback to let traffic roll out gradually while custom instrumentation logs method, args, stack traces and response times. N+1 external calls collapse from thousands→dozens by batching and preloading; payloads shrink from 40 fields to 4 with server-side filtering; a bad sanitizer once caused millions of records to be fetched and CPU/memory spikes ~20x, but iterative monitoring, fixes and rate limiting produce a final 100% enablement that is unremarkable.
AI-written summary · about
chapters (15)
- 0:00Introduction
- 1:52Friday deployment dilemma
- 3:16Billing service extraction
- 7:32Safe deployment environment
- 10:22Monitoring and visibility
- 13:15N+1 queries and caching
- 16:09Domain knowledge vs tricks
- 17:58GraphQL and filtering
- 21:14Production meltdown recovery
- 24:25Debugging request floods
- 27:59Safe Friday deployments
- 30:09Why we couldn’t optimize perfectly from the start
- 33:22Q&A
- 41:31Q&A defenses
- 43:18Q&A postmortems
related talks
43mAPI Optimization Tale: Monitor, Fix and Deploy (on Friday)
42mFrom REST to distributed GQL
38mNew HotN+1ness -Hard lessons migrating from REST to GraphQL
54mOptimizing performance in Rails apps with GraphQL layer
27mBreak up Monoliths and lay them to REST!
30mRails Performance monitoring: A primer for developers
38mBuilding For Gracious Failure
26mRails Performance Monitoring 101: A Primer for Developers