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

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?