Over the years, we’ve seen many approaches to HTTP API design. While REST APIs are still very popular throughout the industry, they offer no inherent guarantees that the client’s assumptions about the response structures will be valid.

GraphQL fills this gap to an extent by allowing client-side code greater control over the resulting structures but at the cost of added complexity. RPC (remote procedure call) frameworks attempt a different solution by sharing generated type definitions between the client and server implementations. What if there was a way to achieve the type safety of RPC by simply inferring the type definitions from the server’s code?

Enter tRPC. Since JavaScript (and specifically TypeScript) can already span across client and server implementations, tRPC allows a client to directly consume structures defined by the server’s exposed procedures. Essentially, you import your dependencies from the server to access these procedures, their return types are inferred and checked at build time, and your client code can confidently consume the returned data.

In this post, we’ll look at how it achieves these goals and what limitations it places on your project stack.