gRPC is two things to me (please correct me if I'm forgetting something):
- A specification language for services and the RPC calls they take (except RPC response primitives include single message and stream)
- A binary object definition/packing scheme (aka protobuf)
Outside of the HTTP and what HTTP/2 makes possible, I feel vaguely like everyone is rushing to replace pure HTTP/HTTP2 (and HTTP3 in the future) with something that is less extensible and could be implemented inside HTTP for the most part.
Obviously you can't do anything about the inefficiencies of headers in HTTP/1 (this is better in HTTP/2 & 3), the lack of built-in stream semantics (again only HTTP/1 though you can make do with some longpolling/SSE/websockets scheme) but outside of the HTTP stuff you can absolutely transmit your content as a stream of tightly packed bytes and let consumers do whatever they need to...
Why is gRPC anything more than a content type? It's so weird to see gRPC evolve from (in some sense, I might be wrong) HTTP + HTTP/2, and now people trying to shoe horn it back into the browser.
It's really hard to find metrics (maybe I should do a comparison and post results I guess), but like in this SO post[0]. The hype train is presenting gRPC as the next thing, but it shouldn't be, IMO. Most of the improvement is from use of protobuf for more efficient (de)serialization -- and I don't think gRPC is the best tool for declaring API schemas (RPC or otherwise) either.
[0]: https://stackoverflow.com/questions/44877606/is-grpchttp-2-f...
I think what you describe is the shortcoming of the initial grpc spec. It was for some reason decided to define it on top of features which are barely implemented outside of HTTP/2 and special libraries (especially: Trailers). But it would have been possible to just define things on top of common HTTP semantics. This is what grpc-web now fixes according to my understanding.
I think even streaming should have been possible with HTTP/1.1. Bodies can be streamed there just fine, if libraries support it (for browsers the issue was up to now that the APIs don't support access to bodies as streams). The only thing I'm not sure if there is an issue in HTTP/1.1 with request streams still running while the response stream has already finished.
This is also my understanding (minus the Trailers bit) -- there's stuff like grpc-gateway[0] that I've considered using before so I know there's a mapping (whether it's easy to use is another thing) from grpc to HTTP/1.1 ...
> I think even streaming should have been possible with HTTP/1.1. Bodies can be streamed there just fine, if libraries support it (for browsers the issue was up to now that the APIs don't support access to bodies as streams). The only thing I'm not sure if there is an issue in HTTP/1.1 with request streams still running while the response stream has already finished.
For streaming I was thinking mostly of the duplex streams, i.e. what Websockets brought to the table, everything else would be pretty hacky. I suspect that grpc translates to regular browser-ready HTTP/1.1 REST pretty easily (outside of trying to decide how), minus the streaming bit, since you'd have to do some sort of comet/long polling/sse/websockets approach.