Because you lose all the stuff that’s nice about tRPC.
The experience of building a tRPC app is very different from building an app that talks to a traditional REST API. The front and back end with tRPC are very tightly bound. In a way the backend part of your tRPC app becomes the real consumer of your actual API.
Okay. I see 3 main benefits of the tRPC experience.
1. You don't need to manually write HTTP routes on the server side.
2. You don't need to manually write request code on the client side.
3. There's a type contract between both.
I don't see how this "thin server" approach helps with any of these.
1. You're no longer writing HTTP routes, but instead you're writing gRPC. You haven't eliminated the work, you've just changed the technology. If you happen to be integrating with a pre-existing gRPC deployment, why re-invent the wheel with custom TS code instead of using one of the many gRPC->HTTP transcoders?
2. Modern web frameworks have so many abstractions on this pattern that it's a non-issue at this point.
3. Your thin server is effectively a mapper from gRPC to HTTP endpoints. That's the type of thing you can build a spec from. If you've used a transcoder and have a spec, you can codegen your client library with the correct types.
I think tRPC works best for making highly cohesive full stack apps. Using it as a middleman for your backend seems weird to me.
