I was really excited when I saw the headline, but I was kind of disappointed to see it doesn't support schemas natively. I know you can specify them via zod, but I'm really not looking forward to any more untyped APIs, given that the lack of strict API typing has been by far the #1 reason for the bugs I've had to deal with in my career.

▲ kentonv 4 days ago | parent [-]

I really want to bake in some sort of support for generating type checks based on TypeScript types... so then your schemas are just TypeScript. Not sure why this doesn't seem to be a common practice TBH, might be missing something.

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

We built our own in-house RPC interface definition pipeline where the schemas are just typescript types, looking very similar to the example in your post

    interface MyService {
      method(): ReturnType;
    }

We parse the typescript to JSON Schema, then use that to generate runtime validation across both JS implementations and other languages.

Typescript is a really nice IDL. I didn't want to hitch our wagon to something else like typespec.io even if that would have given us more things out of the box.

▲ ryanrasti 4 days ago | parent | prev | next [-]

> Not sure why this doesn't seem to be a common practice TBH, might be missing something.

Yeah... I've been deep in this problem space myself. The two big points of friction are: 1. Requiring a build-step to generate runtime code from the TS types 2. TS doesn't officially support compiler transforms that do it

That said, the two most promising approaches I've found so far: 1. https://github.com/GoogleFeud/ts-runtime-checks -- it does exactly what you describe 2. https://arktype.io/ -- a very interesting take on the Zod model, but feels like writing native Typescript

Congrats on the launch, really exciting to see a way to get capabilities into the JS ecosystem!

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

That would be great, would these checks run at deserialization time? They'd probably need to, as you wouldn't want to assume that the stuff coming through the network is of a specific type.

▲

kentonv 4 days ago | parent [-]

I'm thinking the ideal would be if I could feed in a TypeScript interface, and have some tool generate a wrapper around that interface which type-checks all inputs.

This tool could actually be totally independent from the RPC implementation.

I don't think it's necessary to bake type checks into the deserialization itself, since the RPC system already doesn't make any assumptions about the payloads it is moving around (other than that they are composed of only the types that the deserialization supports, which is a fixed list).

	▲	stavros 4 days ago \| parent [-]
		I understand your reasoning, but this is one of those things where people will use the default, and your choice as designer is whether you'll have the default that makes it harder to get started with, but reduces bugs down the line, or whether you'll make it easier to get started with, but much more buggy. History has shown that, if you want things to be popular, you should choose the latter, but I think the tide has turned enough that the former could be the right choice now. That's also the reason why we use Typescript instead of JS, so mandatory static typing would definitely fit with the zeitgeist. Honestly, the boundary is the one place where I wouldn't want to not have types.