always felt like grpc was unnecessarily inaccessible to the rest of us outside google land. the grpc js client unnecessarily heavy and kinda opaque. good idea but poorly executed compared to people who are familiar with the "simplicity" of REST
RPCs have more maintainable semantics than REST as a virtue of not trying to shoehorn your data model (cardinality, relationships, etc.) into a one-size-fits-all prescriptive pattern. Very few entities ever organically evolve to fit cleanly within RESTful semantics unless you design everything upfront with perfect foresight. In a world of rapidly evolving APIs, you're never going to hit upon beautiful RESTful entities. In bigger teams with changing requirements and ownership, it's better to design around services.
The frontend folks don't maintain your backend systems. They want easy to reason about APIs, and so they want entities they can abstract into REST. They're the ultimate beneficiaries of such designs.
The effort required for REST has a place in companies that sell APIs and where third party developers are your primary customers.
Protobufs and binary wire encodings are easier for backend development. You can define your API and share it across services in a statically typed way, and your services spend less time encoding and decoding messages. JSON isn't semantic or typed, and it requires a lot of overhead.
The frontend folks natively deal with text and JSON. They don't want to download protobuf definitions or handle binary data as second class citizens. It doesn't work as cleanly with their tools, and JSON is perfectly elegant for them.
gRPC includes excellent routing, retry, side channel, streaming, and protocol deprecation semantics. None of this is ever apparent to the frontend. It's all for backend consumers.
This is 100% a frontend / backend tooling divide. There's an interface and ergonomic mismatch.
REST is kind of like HTML... source available by default, human-readable, easy to inspect
GRPC is for machines efficiently talking to other machines... slightly inconvenient for any human in the loop (whether that's coding or inspecting requests and responses)
The different affordances make sense given the contexts and goals they were developed in, even if they are functionally very similar.
https://buf.build/blog/protobuf-es-the-protocol-buffers-type...
and also canonical content streaming was in grpc. in http there was no common accepted solution at old times.
SSE was first built into a web browser back in 2006. By 2011, it was supported in all major browsers except IE. SSE is really just an enhanced, more efficient version of long polling, which I believe was possible much earlier.
Websocket support was added by all major browsers (including IE) between 2010 and 2012.
gRPC wasn't open source until 2015.
binary with schema separation.
3x smaller payload.
- 1. multiplexing protocol implemented on top of HTTP/2 - 2. serialization format via protobuf
For most companies, neither 1 or 2 is needed, but the side effect of 2 (of having structured schema) is good enough. This was the idea behind twrip - https://github.com/twitchtv/twirp - not sure whether this is still actively used / maintained, but it's protobuf as json over HTTP.
so once you wrote grpc, you get open api rpc for free.