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…
TRPC: End-to-end typesafe APIs made easy
31–40 of 59 posts
Re: TRPC: End-to-end typesafe APIs made easy
#32Re: TRPC: End-to-end typesafe APIs made easy
#33I am really not getting this. If you run Typescript on both ends, can't you just share the source code that defines the types?
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
#34I’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.
Re: TRPC: End-to-end typesafe APIs made easy
#35tRPC 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…
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
#36I 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…
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
#37Re: TRPC: End-to-end typesafe APIs made easy
#38Re: TRPC: End-to-end typesafe APIs made easy
#39This 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/
See this for more info: https://github.com/trpc/trpc/issues/1724
Re: TRPC: End-to-end typesafe APIs made easy
#40How 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