Live data from Hacker News

TRPC: End-to-end typesafe APIs made easy

trpc.io

41–50 of 59 posts

Re: TRPC: End-to-end typesafe APIs made easy

#42
post #6

Only supports using Javascript/node servers it seems, so sadly it's not really usable for me. The type exchange seems to rely on shared code between the frontend and the backend to exchange types, rather than using schemas like other systems. Not implementing server-side events seems like a shame because they're a very capable mechanism for subscriptions without resorting to websockets.

I don't believe there's anything really preventing the use of server-side events. The Websocket implementation is via an adapter and special client so I think the same could be done for SSE (probably achievable in an external package too).

Re: TRPC: End-to-end typesafe APIs made easy

#43
post #33

I am really not getting this. If you run Typescript on both ends, can't you just share the source code that defines the types?

You kinda can share function signatures with TypeScript's import type. And that's what tRPC does but adds some generics in the middle to make things seamless. Explanation here: https://colinhacks.com/essays/painless-typesafety

You could argue that this is actually adding a lot of (nicely knit) seams.

Re: TRPC: End-to-end typesafe APIs made easy

#44

I am really not getting this. If you run Typescript on both ends, can't you just share the source code that defines the types?

Basically tRPC lets you define a router containing all your endpoints in a single structure. Then you can import the type definition of your router and make typed API calls without needing to wire everything together with types.

Re: TRPC: End-to-end typesafe APIs made easy

#45

you can't have type-safety with an unsound type system, silly.

Could you elaborate on this? What part of tRPC do you think is unsound due to the type system?

TypeScript's type system is unsound in a mathematical sense: https://effectivetypescript.com/2021/05/06/unsoundness/ Though this has little bearing on practicality which is probably why the original comment is at the bottom of the pile.

He's also using a stricter mathematical definition of "type safety" whereas tRPC means it in the colloquial way it's used in the TypeScript ecosystem (that is, a fully typed interface between client and server, ideally that's non-duplicative and inferred directly from your code instead of being manually defined).

Re: TRPC: End-to-end typesafe APIs made easy

#46
post #33

Earlier quoted context omitted.

You kinda can share function signatures with TypeScript's import type. And that's what tRPC does but adds some generics in the middle to make things seamless. Explanation here: https://colinhacks.com/essays/painless-typesafety

You could argue that this is actually adding a lot of (nicely knit) seams.

I think that's a good characterization!

Re: TRPC: End-to-end typesafe APIs made easy

#47
Not looking to actively bash anyones work here but I’m really confused on the value proposition here over something like gRPC which has a lot of substantial advantages from speed, to wide cross language support and has been battle tested in the most extreme scaling scenarios possible.

A truly huge amount of time, money and optimization went into a project like that and has been proven to work well for years now.

The JS ecosystem confuses me with things like this regularly just the other day I was watching a video where the lead devrel person from Vercel was trying to explain “edge functions” to a senior backend engineer that started falling apart under the most rudimentary questioning so much so that in the video they have this awkward hard cut and they rush to wrap up the interview. Link if anyone is interested https://youtu.be/yuxd2kurpzk

This gives me kind of similar vibes in that I just don’t really get the use case here unless it’s to intentionally stay strictly in the JS ecosystem for some reason?

Re: TRPC: End-to-end typesafe APIs made easy

#49

Earlier quoted context omitted.

Could you elaborate on this? What part of tRPC do you think is unsound due to the type system?

TypeScript's type system is unsound in a mathematical sense: https://effectivetypescript.com/2021/05/06/unsoundness/ Though this has little bearing on practicality which is probably why the original comment is at the bottom of the pile. He's also using a stricter mathematical definition of "type safety" whereas tRPC means it in the colloquial way it's used in the TypeScript ecosystem (that is, a fully typed interface…

Thanks for clarifying!
Post reply on HN