Live data from Hacker News

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

aws.amazon.com

1–10 of 156 posts

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

#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.

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

#5
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 use case is companies that want to use SOAP but don't want to say they use SOAP

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

#6
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 connection multiplexing, ...

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

#8

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

Serialization/deserialization speed and reducing transfer size are good reasons for large throughput service-to-service communication. Also a decent ecosystem around code generation from .proto files and gateways to still support some level of JSON-based calls.

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

#9

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 whilst being compatible with the transport protocol and other things. Also if you were to route a payload from service A via B to C and each service is deployed independently and gets new Api changes, gRPC supports you in how to handle ther Szenarios.

Sure enough openapi can do all of this I guess but grpc definitions in Protobuf or Google artman are just way quicker to understand and work with. (At least for me)

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

#10

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

Sure. You would use gRPC when:

    - You want to have inter-service RPC.
    - You want not only unary calls, but also bidirectional streaming.
    - You want a well-defined schema for your RPC data and methods.
    - You want a cross-language solution that guarantees interoperability (no more JSON parsing differences! [1])
[1] - http://seriot.ch/parsing_json.php
Post reply on HN