You can use TypeScript to define your API, and get all the benefits of schemas.

Well, except you don't get runtime type checking with TypeScript, which might be something you really want over RPC. For now I actually suggest using zod for type checks, but my dream is to auto-generate type checks based on the TypeScript types...

▲ ngrilly 4 days ago | parent [-]

Then that means we have to define the interface twice: once in TypeScript and another in Zod?

▲ kentonv 4 days ago | parent [-]

No. Zod gives you TypeScript types corresponding to the schema. So you would only need to write the schema in Zod.

(I do wish it could be the other way, though: Write only TypeScript, get runtime checks automatically.)

▲ sebws 4 days ago | parent | next [-]

There are ways if you're ok with a build step, e.g. https://typia.io/ or https://github.com/GoogleFeud/ts-runtime-checks

Although perhaps that's not what you mean.

I found these through this https://github.com/moltar/typescript-runtime-type-benchmarks

▲ ngrilly 4 days ago | parent | prev [-]

I'm familiar with zod.infer but I'm not sure how to use it to produce an interface that would be compatible with RpcStub and RpcTarget, like MyApi in the example in your post:

  // Shared interface declaration:
  interface MyApi {
    hello(name: string): Promise<string>;
  }

  // On the client:
  let api: RpcStub<MyApi> = newWebSocketRpcSession("wss://example.com/api");

  // On the server:
  class MyApiServer extends RpcTarget implements MyApi {
    hello(name) {
      return `Hello, ${name}!`
    }
  }

	▲	kentonv 4 days ago \| parent [-]
		I'll be honest and say I haven't tried it myself. But my expectation is you'd use Zod to define all your parameter types. Then you'd define your RpcTarget in plain TypeScript, but for the parameters on each method, reference the Zod-derived types.