Achieving end to end typesafety
summary
Claim: a working end-to-end type-safe API stack that removes client-side service types and gives immediate compile-time errors when backend changes. Implements tRPC + React Query on the front end, Express (or Next) adapters on the server, uses Zod validation for inputs and can infer outputs from Prisma or other backends. Team converts existing Firebase/Express code quickly (one engineer in ~1–2 days), backend types become backend types as source of truth and it reduces runtime mismatch bugs.
AI-written summary · about
chapters (19)
- 0:00Introduction and speaker intro
- 1:07Story of best Dev experience
- 4:19Problems with shared types approach
- 7:50Why loose coupling fails
- 9:58Why we chose tRPC
- 11:04tRPC basics: queries and mutations
- 13:14tRPC integration with Express
- 16:48Frontend setup with tRPC
- 18:55End-to-end type safety explained
- 21:43Benefits after switching to tRPC
- 23:08Source of truth: backend types
- 24:57Permissions and middleware
- 25:39Live demo introduction
- 27:48Demo: form with type safety
- 28:52Demo: breaking changes feedback
- 30:15Why not GraphQL
- 31:41Tight coupling benefits
- 32:24Main takeaways and summary
- 33:56Q&A
related talks
35mFull-stack Type Safety with React, GraphQL, and TypeScript
10mEnd-to-end Type Safety
26mFull Stack Type Safety with React, GraphQL, and TypeScript
27mTake a rest from REST
05mFull-stack & Typesafe React (+Native) Apps with tRPC.io
24mEnd to End type safety: A tale of three domains
12mtRPC: Better than REST GraphQL?
13mMaking typesafe APIs easy with tRPC