Comment by mhoad | Hacker News Reader

Comment by mhoad | Hacker News Reader

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?

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?

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 :)

Reply on news.ycombinator.com