Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TRPC: End-to-end typesafe APIs made easy

trpc.io

Post reply on HN
Print view View original

51–59 of 59 posts

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

#51

Post by awhitty »

alexdotjs wrote: post #39
awhitty wrote: 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

Thanks for the link! That looks really stellar actually. Excited to see how it shapes up.

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

#52

Post by sachinraja »

mhoad wrote: post #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…

You can't provide typesafety (with TypeScript) across the frontend and backend for multiple languages without codegen. There's no intention for this to be strictly JS, but there's no easy way to offer this for multiple languages.

There will be an openapi generator some time in the future so that could help with generating clients for other languages (https://github.com/trpc/trpc/issues/1724).

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

#53

Post by rad_gruchalski »

sachinraja wrote: post #52
mhoad wrote: post #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…

You can't provide typesafety (with TypeScript) across the frontend and backend for multiple languages without codegen. There's no intention for this to be strictly JS, but there's no easy way to offer this for multiple languages. There will be an openapi generator some time in the future so that could help with generating clients for other languages ( https://github.com/trpc/trpc/issues/1724 ).

So what problem does this solve? Protobuf + grpc already provide types for tons of languages. As in, messages are generated to models/structs/classes what have you, depending on the language…

OpenAPI already exists and anyone can write a spec today and have code generated (servers, clients, models) today. Same principle as protobuf but the message and service description is much more verbose.

> tRPC to OpenAPI generator

So, … another level of indirection? Why would I ever pick this up when I can just use OpenAPI directly?

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

#54

Post by mhoad »

sachinraja wrote: post #52
mhoad wrote: post #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…

You can't provide typesafety (with TypeScript) across the frontend and backend for multiple languages without codegen. There's no intention for this to be strictly JS, but there's no easy way to offer this for multiple languages. There will be an openapi generator some time in the future so that could help with generating clients for other languages ( https://github.com/trpc/trpc/issues/1724 ).

I think maybe that’s the part I’m not getting.

I don’t have a problem with the code generation personally, if anything I appreciate having something I can go and inspect if things go wrong so avoiding it isn’t an obvious plus to me.

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

#56

Post by sachinraja »

mhoad wrote: post #54
sachinraja wrote: post #52

Earlier quoted context omitted.

You can't provide typesafety (with TypeScript) across the frontend and backend for multiple languages without codegen. There's no intention for this to be strictly JS, but there's no easy way to offer this for multiple languages. There will be an openapi generator some time in the future so that could help with generating clients for other languages ( https://github.com/trpc/trpc/issues/1724 ).

I think maybe that’s the part I’m not getting. I don’t have a problem with the code generation personally, if anything I appreciate having something I can go and inspect if things go wrong so avoiding it isn’t an obvious plus to me.

Using TS type inference to its fullest is a major part of tRPC so I don't think it has much of a benefit to you if you're ok with generation.

In my experience, you can iterate more quickly without generation. I've used GraphQL and having a separate system to generate code and types was not a good experience. If not done properly, your schema and types can also easily be out of sync.

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

#57

Post by mhoad »

sachinraja wrote: post #56
mhoad wrote: post #54

Earlier quoted context omitted.

I think maybe that’s the part I’m not getting. I don’t have a problem with the code generation personally, if anything I appreciate having something I can go and inspect if things go wrong so avoiding it isn’t an obvious plus to me.

Using TS type inference to its fullest is a major part of tRPC so I don't think it has much of a benefit to you if you're ok with generation. In my experience, you can iterate more quickly without generation. I've used GraphQL and having a separate system to generate code and types was not a good experience. If not done properly, your schema and types can also easily be out of sync.

Never worked with GraphQL only gRPC which in my setup at least has an extremely tight feedback look in that code gen is almost instant and triggered on a file save of a proto file (which is where you define your interfaces in that particular ecosystem) which again sounds like maybe where my confusion is coming from, none of the pain points you mentioned have ever been a problem for me but if it works for you then more power to you, not here to say you’re wrong :)

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

#59

Post by tome »

lalaithion wrote: post #34
Vosporos wrote: post #30

Earlier quoted context omitted.

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

There's a huge gulf here. undefined doesn't introduce unsoundness, and unsafePerformIO isn't part of the language standard, it's strongly discouraged, and rarely used. I've been writing Haskell professionally for 10 years, for example, and I've never written unsafePerformIO.
Post reply on HN