Hacker News Reader

Comment by kyrra | Hacker News Reader

There is the possibility of grpc, but there hasn't been a case for it yet (hence why none of our docs even mention it). Google also loves talking grpc/stubby internally, so any Google internal application to application calls would use that.

View on HN

Pardon my ignorance but why does it matter that you're using RPC/graphQL or REST based service, isn't the underlying protocol still HTTP? So this spec would still be applicable, right?

AFAIK, in Google's case the end application doesn't really see the "GRPC HTTP headers" but instead they convert an incoming HTTP request to one of their frontends and route it to multiple backends (sending effectively the HTTP body serialized via GRPC), and then the frontends will simply re-create the response by unifying them.

Not a Googler, this is what I understood from reading similar things over multiple posts. Feel free to correct me.

The underlying protocol is not necessarily HTTP.

I think it is necessarily HTTP/2, but would be happy to learn I'm mistaken - it's not something I'm overly confident about.

https://developers.googleblog.com/2015/02/introducing-grpc-n...

gRPC uses HTTP/2.0 yes, so headers are a concept, but imagine taking it one step further, for instance using WebSockets. There is no concept of headers within an individual WebSocket message, so it would need to be encapsulated in an application-specific way anyway.

Reply on news.ycombinator.com