TRPC: End-to-end typesafe APIs made easy

I wrote the initial proof of concept for tRPC a little over a year ago (though I'm no longer involved in the project). Seems like there's some confusion about how this works. A more complete description is available here[0] below but I'll put a brief explanation below as well.

- It's designed specifically for a full-stack TypeScript app. Your API is implemented as strongly typed server-side functions.

- The input type is specified using a schema library like Zod or io-ts.

- TypeScript infers the return type of these functions.

- You can then import the type signatures of your functions into your client. Just types, no runtime code! This is safe in typescript with the `import type` syntax. tRPC uses those type signatures to provide a typesafe client API, basically an SDK for your API. There's no codegen happening - the client uses TypeScript generics to provide a set of strongly typed "proxy functions" that can be "called" on the client. These proxy functions execute HTTPs requests under the hood: https://trpc.io/docs/rpc

The point is to avoid the boilerplate, codegen, and lack of DRYness associated with building a strongly typed API in TypeScript. You can do this with GraphQL but it relies on code-generation, requires complete buy-in, and (IMO) doesn't provide a great developer experience. TypeScript has a native way of representing types, so the goal is to avoid an intermediate representation (in the form of an OpenAPI spec or GraphQL schema) entirely. As you update your server code, the client's type signatures update instantaneously.

Another important goal is to make it easy to write DRY code when building APIs. Without tRPC, it's common to manually provide type definitions for the results of API calls. But those definitions can easily get out of sync with your actual server code. tRPC infers types from your code itself and provides a typed interface for your API thats doesn't require any manual type annotations.

[0] https://colinhacks.com/essays/painless-typesafety

I like this idea very much. Shameless plug and I don't want to be the Rust fanboy, but I've played with something similar in Rust:

https://github.com/julienr/liveboard-rs

Basically it uses actix for the backend and yew (Vue-like rust frontend framework) for the frontend. This enables one to share types (and helper functions) between both, which is great:

https://github.com/julienr/liveboard-rs/blob/master/shared/s...

That being said, I think maturity-wise, Typescript is probably a better bet for this right now, so I'll definitely look at trpc for $dayjob.

So essentially, it's protobuf but it describes the API instead of a message (which arguably is also an API description) and is for TypeScript on both sides.

I recently gave a talk about our experience with tRPC. So far it's looking very promising!

https://www.youtube.com/watch?v=k1TCueEhhJo