I'm not too surprised. Most people for whom TypeScript is an option won't have been exposed to generations of RPCs that fail to deliver simplicity. So it isn't going to be on their radar.
I've been using gRPC and REST'ish+JSON APIs for years now and what I find puzzling is that REST+JSON tends to mean a lot more work, less pleasing code than gRPC, and yet people prefer it. Not because it leads to simpler, better, faster less error prone code (it doesn't. Quite the opposite), but, I think, because people feel they can understand it.
The people over at https://buf.build have been doing a great job trying to tame gRPC btw. The protoc toolchain from Google has been uniquely horrible to work with, but the 'buf' tool from said company has been a real life-saver. Not to mention their Buf Schema Registry, which admittedly I have only used on a few projects so far, but should migrate more projects to.
Though in general, I feel that RPC mechanisms that are too closely tied to a given language are a waste of time. But that's me. tRPC isn't something I'd get into even if I was doing server side TS. It just doesn't seem like a good long term choice.
"I feel that RPC mechanisms that are too closely tied to a given language are a waste of time" - THIS RIGHT HERE! - The whole point is to allow people using different languages to collaborate - your analysts using python/R should be able to talk to your Java/C++/Rust/C#/Go folks and web-frontends (and server sometimes) Typescript/Javascript/etc.
One of the worst example (in the past) was the python pickle. People have overused it, and it's not even compatible between some python releases. There are many other examples - where something works really neat, but only for that language, or even that language major or even just minor release.
There is protobuf, cap'n'proto, flat buffers, fidl, thrift, etc. - many better choices than just one that works only for your language.
People sticking with REST+Json usually don't want to have a compilation step for the API exchanges layer. That means more validation and worse tooling, but also better legacy and potentially future compatibility, and way easier debugging at any stage.
I feel this is the same debate between scripting languages and compiled languages, both provide different trade-offs and I don't think we'll see one completely disappear at any point in time.
> People sticking with REST+Json usually don't want to have
> a compilation step for the API exchanges layer.
Hmm. I'm not sure what you are saying.
The way people tend to try to consume REST APIs is by generating client (and/or server code) from a spec. For instance OpenAPI 2.0. At least on Go the tooling for that leaves something to be desired, and the generated code isn't exactly beautiful. So you either depend on a library that someone generates from the spec, and then shares, or you generate it yourself.
(We do this for a bunch of languages for our APIs, and the clients are ... not uniformly beautiful :-))
If we're talking about writing the REST client by hand...well...I'm not sure why one would want to do that. (Nor am I sure that's what you meant, so I'm not accusing you of that).
My current workflow (in Go) for consuming gRPC interfaces is to use the buf.build package proxy. Which means I just add an import, run go mod tidy, and I'm good. I don't even need the tooling installed. As I think it should be.
I suppose this could be done for OpenAPI 2.0 too. You stuff OpenAPI 2.0 specs in and you get code for a bunch of languages out. (Someone must surely have built this already?)
I agree that sticking to just a library may be not a good choice. Some standard would be better. But few last times I discussed it, some folks just slapped RPC stigma on everything, even if it was just your regular REST-y-ish calls underneath. That’s absurd. POST json receive json back is okay. Wrap it into an `await server.<method>(<args>)` call and now it’s an RPC mudball. The current top commenter is removing tRPC for tight coupling. I wonder what prevents them from tight coupling over http, or over just function calls when on the same “side”. It’s a mindset that they are removing, not a specific technology.
Careful what you wish for. Standards that aren't quite good enough can be worse than not having standards. Because then at least then people will keep looking for something that might be better.
