Live data from Hacker News

TRPC: End-to-end typesafe APIs made easy

trpc.io

31–40 of 59 posts

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

#31

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 typ…

What's the backwards compatibility story here? What changes to backend function argument and return types can I make without breaking currently-open webpages when I push a new backend instance?

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

#32
This project looks interesting! I have used a similar project called tsoa [1] and have appreciated that it generates an OpenAPI spec that can be consumed readily by many other clients, even outside the JS ecosystem. Does TRPC have plans for a similar feature set?

[1] https://tsoa-community.github.io/docs/

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

#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

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

#34
post #3

I’ve never used this, but it looks like a very similar idea to Haskell’s Servant library [ https://docs.servant.dev/en/stable/ ]. Could someone who knows more enlighten me as to how correct this comparison is?

Hi, Servant user here: Haskell's type system is sound, which means that you can have type safety. TypeScript's type system is unsound, so every guarantee that you may think you have wrt. type safety go out of the window at the moment you start the typechecker.

Hey, don't be this way. Haskell's type system is also unsound (see: undefined, unsafePerformIO). Typescript has done an amazing job bolting an advanced static type system on top of a dynamically typed language. The edge cases of that type system exist, and are a bit more prevalent than Haskell's, but there exist a number of libraries in Typescript that take inspiration from Haskell libraries. This question is about the differences between the design of these two ways of statically representing APIs and not about the fundamental differences in the type systems of their host languages.

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

#35
post #29

tRPC has been a lifesaver for us at Ping.gg Never had such a seamless experience building and deploying “full stack” apps. Multiple classes of bugs just, like, don’t happen now? Helped build up a lot of the GraphQL tech at twitch, and I still love it, but man do I not miss all the work maintaining the “contract” between front and back. I know we will have to move off tRPC eventually, but I’m hyped at how far it’s tak…

> I know we will have to move off tRPC eventually

Is that when you can no longer get by with only NodeJS/TypeScript on the backend?

I've been thinking about that in a greenfield project I'm trying tRPC out.

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

#36

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 typ…

This is very cool, thanks so much for explaining how this works and, of course, for initiating such a cool project!

As far as I can tell, tRPC basically bridges (hides) network communication and allows doing remote procedure calls almost like regular, type-safe function calls on the same machine within the same process.

Now I would give a fortune for having something like that also for cross-language communication and for communicating with other processes (binaries and shell scripts). I've been thinking about this a lot in recent years: In SWE we need to jump through many hoops only because it's so god damn hard to invoke a function or a whole API living somewhere else in a type-safe manner. Intermediate formats like JSON, protobuf, standards like REST, OpenAPI, and GraphQL, and even languages like SQL (and the various ORM libraries it inspired) are all a result of that to some degree: Once data leaves the safe haven of your (hopefully statically typed) programming language where the compiler/interpreter knows exactly what its type is and what the signature of the function is that you're trying to call, you're basically on your own.

I recently read about WASM Interface Types[0] and it seems like a step in the right direction, though unfortunately it will only bridge the – let's call it – type safety gap between processes, not between different machines in a network.

[0]: https://hacks.mozilla.org/2019/08/webassembly-interface-type...

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

#38
I'm not seeing the appeal of this over Smithy, which can target multiple frontend and backend languages. What am I missing? What is wrong with codegen tools? Especially when they help you design strong contracts upfront, rather than ad-hoc API design as their demo shows.

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

#39
post #32

This project looks interesting! I have used a similar project called tsoa [1] and have appreciated that it generates an OpenAPI spec that can be consumed readily by many other clients, even outside the JS ecosystem. Does TRPC have plans for a similar feature set? [1] https://tsoa-community.github.io/docs/

Yup, with the optional `output`-property we actually have all the type information needed to generate an openapi-schema.

See this for more info: https://github.com/trpc/trpc/issues/1724

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

#40

How does this compare to gRPC? That the wire protocol is actually http+json instead of binary? I wasn't able to find much on their website

tRPC offers typesafety across your frontend and backend without needing to generate any code. This makes it so updates in your backend "router" are immediately reflected in your frontend code. You can't use gRPC with TypeScript without codegen. tRPC may be more familiar to TS/Node.js devs too.
Post reply on HN