Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Application Load Balancers enables gRPC workloads with end to end HTTP/2 support

aws.amazon.com

Post reply on HN
Print view View original

11–20 of 156 posts

Re: Application Load Balancers enables gRPC workloads with end to end HTTP/2 support

#11

Post by k__ »

q3k wrote: post #6
k__ wrote: post #3

Half-OT: What's the main use-case for gRPC? I had the impression RPC was seen as a mistake. Sure, gRPC also uses a binary protocol, but that doesn't seem like a USP of gRPC. Why didn't they went fron non-RPC binary? Serious question! It sounds a bit counterinuitive to me at the first glance.

It's a generic RPC protocol based on a well-enough-typed serialization format (protobuf) that is battle-tested. You'd use it where you'd use REST/API/JSONRPC/... Compared to plain JSON/REST RPC, it has all the advantages of protobuf over JSON (ie. strong typing, client/server code generation, API evolution, etc), but also provides some niceties at the transport layer: bidirectional streaming, high quality TCP connect…

Thanks for the explanation!

Why wouldn't it be enough to use REST with a protobuf media type?

Re: Application Load Balancers enables gRPC workloads with end to end HTTP/2 support

#14

Post by q3k »

k__ wrote: post #11
q3k wrote: post #6

Earlier quoted context omitted.

It's a generic RPC protocol based on a well-enough-typed serialization format (protobuf) that is battle-tested. You'd use it where you'd use REST/API/JSONRPC/... Compared to plain JSON/REST RPC, it has all the advantages of protobuf over JSON (ie. strong typing, client/server code generation, API evolution, etc), but also provides some niceties at the transport layer: bidirectional streaming, high quality TCP connect…

Thanks for the explanation! Why wouldn't it be enough to use REST with a protobuf media type?

There is some support for that [1]. I prefer to use native binary gRPC because:

1) REST verb/code mapping is too arbitrary for my taste, I prefer explicit verbs in RPC method names and error codes explicitly designed for RPC [2] and ones that will not be accidentally thrown by your HTTP proxy thereby confusing your client

2) REST stream multiplexing over a minimum amount of TCP connections is difficult to do, I trust the gRPC authors to have done their homework better than the average HTTP library. In addition, you can multiplex multiple gRPC bidirectional streams over a single TCP connection, which is something you can't do over plain HTTP without resorting to websockets.

[1] - https://cloud.google.com/endpoints/docs/grpc/transcoding

[2] - https://github.com/grpc/grpc/blob/master/doc/statuscodes.md

Re: Application Load Balancers enables gRPC workloads with end to end HTTP/2 support

#15

Post by wongarsu »

k__ wrote: post #3

Half-OT: What's the main use-case for gRPC? I had the impression RPC was seen as a mistake. Sure, gRPC also uses a binary protocol, but that doesn't seem like a USP of gRPC. Why didn't they went fron non-RPC binary? Serious question! It sounds a bit counterinuitive to me at the first glance.

> I had the impression RPC was seen as a mistake.

Aren't REST and webhooks just RPC protocols too?

Re: Application Load Balancers enables gRPC workloads with end to end HTTP/2 support

#16

Post by k__ »

weitzj wrote: post #9
diogenesjunior wrote: post #4

Can somebody please explain to me why we would use gRPC?

It makes it really nice to define APIs (like with Openapi of swagger). There is a bunch of code generators out there to produce code for your definitions to have a native swift , objective , Java, Go api stubs for either clients or servers. It is a joy to work with in cross functional teams and define your APIs whilst taking into account what Api versioning would mean, how to define enums, how to rename field names w…

I see, cool.

So the spec already includes versioning?

Re: Application Load Balancers enables gRPC workloads with end to end HTTP/2 support

#18

Post by benreesman »

I started a recent project with gRPC but wound up moving to fbthrift after having a bad time with the C++ async server story. Overall I’d like to be using gRPC because the fbthrift documentation is weak, but thread-per-request is a non-starter for some use cases. From the gRPC source it looks like they’ve got plans to do something about it but it seems a ways off.

Re: Application Load Balancers enables gRPC workloads with end to end HTTP/2 support

#19

Post by q3k »

k__ wrote: post #16
weitzj wrote: post #9

Earlier quoted context omitted.

It makes it really nice to define APIs (like with Openapi of swagger). There is a bunch of code generators out there to produce code for your definitions to have a native swift , objective , Java, Go api stubs for either clients or servers. It is a joy to work with in cross functional teams and define your APIs whilst taking into account what Api versioning would mean, how to define enums, how to rename field names w…

I see, cool. So the spec already includes versioning?

No, gRPC/protobuf instead provides you with ways to evolve your schema easily in the IDL and the result on the wire, without breaking either side.

You can rename fields (but keep the tag number and therefore wire format compatibility), add fields (which will be ignored by the other side), remove fields (as all are explicitly optional so every consumer explicitly checks for their presence anyway), ignore unset fields (as the wire encoding is to a certain-degree self-describing), etc.

Re: Application Load Balancers enables gRPC workloads with end to end HTTP/2 support

#20

Post by k__ »

q3k wrote: post #14
k__ wrote: post #11

Earlier quoted context omitted.

Thanks for the explanation! Why wouldn't it be enough to use REST with a protobuf media type?

There is some support for that [1]. I prefer to use native binary gRPC because: 1) REST verb/code mapping is too arbitrary for my taste, I prefer explicit verbs in RPC method names and error codes explicitly designed for RPC [2] and ones that will not be accidentally thrown by your HTTP proxy thereby confusing your client 2) REST stream multiplexing over a minimum amount of TCP connections is difficult to do, I trust…

Good points.

Thanks again!

Post reply on HN