REST vs tRPC

The architectural style that made APIs boringly reliable, but sometimes too rigid for modern needs meets typescript's love letter to api developers. Here's our take.

REST

Nice Pick

The architectural style that made APIs boringly reliable, but sometimes too rigid for modern needs.

Pros

• Stateless design simplifies scaling and caching
• Uses standard HTTP methods for predictable operations
• Widely supported across languages and platforms

Cons

• Can lead to over-fetching or under-fetching data
• Lacks built-in real-time capabilities

tRPC

TypeScript's love letter to API developers. Write types once, cry about mismatched schemas never.

Pros

• End-to-end type safety without code generation
• Seamless autocompletion and real-time error prevention
• Reduces boilerplate by sharing types between client and server

Cons

• Tightly coupled to TypeScript, limiting use in non-TypeScript projects
• Can feel like magic, making debugging more opaque when things go wrong

The Verdict

Use REST if: You want stateless design simplifies scaling and caching and can live with can lead to over-fetching or under-fetching data.

Use tRPC if: You prioritize end-to-end type safety without code generation over what REST offers.

The Bottom Line

REST wins

The architectural style that made APIs boringly reliable, but sometimes too rigid for modern needs.