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: End-to-end typesafe APIs made easy
21–30 of 59 posts
Re: TRPC: End-to-end typesafe APIs made easy
#22> without schemas What is a type definition if not a schema?
Conceptually, yes. But type definitions are exported by declarative lines in the same code that runs. Basically the schema is imperative code that runs actual validations, the tRPC methodology simply looks at the inferred types from that code to enforce consistency between client and server rather than parsing an actual static schema artifact (e.g. a .gql file).
Re: TRPC: End-to-end typesafe APIs made easy
#23I 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…
So essentially, it's protobuf but it describes the API instead of a message (which arguably is also an API description) and is for TypeScript on both sides.
Exactly. But with faster iteration speed, more type inference, less overhead, and a TypeScript-native DX.
Re: TRPC: End-to-end typesafe APIs made easy
#24interesting. Kinda like fastify json schema.
Re: TRPC: End-to-end typesafe APIs made easy
#25Awesome to see my lil' baby on the frontpage!
Re: TRPC: End-to-end typesafe APIs made easy
#26I’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?
They seem similar. With Servant you start with a type definition describing your API (using type-level functions), from their docs:
type UserAPI1 = "users" :> Get '[JSON] [User]
In tRPC based on the example it looks like you start by defining and instance then grab the type and export it.
Re: TRPC: End-to-end typesafe APIs made easy
#27you can't have type-safety with an unsound type system, silly.
Re: TRPC: End-to-end typesafe APIs made easy
#28I am really not getting this. If you run Typescript on both ends, can't you just share the source code that defines the types?
Re: TRPC: End-to-end typesafe APIs made easy
#29tRPC 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 taken us already
Re: TRPC: End-to-end typesafe APIs made easy
#30I’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.