The Right Size For GraphQL
summary
Argues that GraphQL is right only when you need a language-agnostic communication layer; shows tRPC + Zod + Drizzle delivering end-to-end TypeScript inference with no type definitions and client-side types updating instantly (even before saving), and demos React Server Components producing server-rendered HTML instead of JSON, reducing client transforms. Notes batching is table stakes, monorepo keeps inference simple, and once multiple languages or mobile clients appear a compiler step or GraphQL becomes necessary. Recommends start simple and adopt GraphQL only after cross-language or team-boundary pain emerges.
AI-written summary · about
chapters (12)
- 0:00Intro
- 0:24About Theo Browne
- 1:25Theo Browne Tweet
- 6:28Complexity
- 7:16Type Safety
- 7:46Batching
- 8:31Separation
- 8:58Reusable logic
- 9:35Compiler
- 9:59Language Support
- 10:25Communication Layer
- 10:53Languages
related talks
33mGraphQL is more than a Typed System
32mFrom learning to thinking in GraphQL
30mGraphQL in the Era of React Server Components
43mGraphQL in the Era of Server Components
21mReact Server Components Vs. GraphQL
30mWhy GraphQL vs. Why not GraphQL
23mHarnessing the Power of GraphQL
24mThe future of Angular client-server communication with GraphQL