Converging Paramount EPG Architectures with GraphQL
summary
Paramount uses a top‑down, phased migration to a federated GraphQL supergraph that stitches language‑specific subgraphs (Node.js, Go, Java) into one layer, deployed across GCP, AWS and on‑premise, with a monorepo, Apollo and WunderGraph router, and client caching. They cut N+1 loads with DataLoader, aim for <200 ms latency at scale (about 900 billion calls/month), resolve conflicting domain models via staged normalization, and migrate legacy REST EPG services into simpler subgraphs for better performance.
AI-written summary · about
chapters (16)
- 0:00Introduction to converging EPG
- 1:50What is EPG and Paramount’s role
- 3:38Challenges in streaming platform APIs
- 6:13Operational challenges in convergence
- 8:06Building trust across engineering teams
- 9:08Technical challenges with multiple languages
- 11:59Top-down approach for GraphQL adoption
- 13:22Simplified EPG architecture overview
- 14:05Phase 1: GraphQL Federated layer
- 17:42Phase 2: Converging data models
- 19:11Phase 3: Merging legacy services
- 20:24Phase 4: Backend convergence goals
- 21:31Tools and frameworks for GraphQL
- 24:43Lessons learned from the journey
- 27:36Mindset shift with GraphQL
- 30:51Q&A session
related talks
25mTransforming the Monolith into a Federated Graph
06mEscape the GraphQL Monolith
59mBuilding Distributed GraphQL APIs
23mA glimpse of GraphQL" Frontend developers’ life is easy now!"
42mFrom REST to distributed GQL
46mMoving to GraphQL
30mDeep Learnings Migrating legacy services to Federated GraphQL
48mApollo Federation: Connecting GraphQL Microservices