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

31–40 of 156 posts

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

#31

Post by k__ »

dragonwriter wrote: post #25
k__ wrote: post #22

Earlier quoted context omitted.

Are they? I thought the difference is, that RPC hides behind a function that looks like it would behave like it was local, but in fact does a remote call and REST explicitly states that things happen remote.

Not only is that not a difference, neither one of those things is true. Any remote interface tends to “hide behind” a local function, that's just how structured programming (of which most more advanced paradigms are refinements) works. And Remote Procedure Call is fairly express that things happen remotely.

Interesting. That's how I learned it, haha.

Thanks for the clarification!

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

#32

Post by mradmin »

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…

> You'd use it where you'd use REST/API/JSONRPC/

Not really. You'd use it for inter service communication but can't really use it in the browser (see grpc-web)

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

#33

Post by sudhirj »

diogenesjunior wrote: post #4

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

If you're communicating between two systems, gRPC has a few benefits: * keeps a socket open between them (HTTP/2) and puts all your method calls on that connection. So you don't have to set up connections on each call or handle your own pooling. * comes with builtin fast (de &)serialization using protobuf. * uses a definition language to generate SDKs for a whole bunch of languages. * makes testing super easy because your testing team, if you have a separate one, can make an SDK in their preferred language and write tests.

Much better developer experience and performance writing HTTP services and code to call them.

Cons are * not being able to use Postman / firebug, nothing on the wire is human-readable * load balancer support is sketchy because of the use of HTTP trailers and full path HTTP/2. That's why AWS ALB supporting it is news. * The auth story isn't very clear. Do you use the out of band setup or add tokens in every single RPC?

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

#34

Post by outworlder »

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

How is it related to SOAP in any way?

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

#35

Post by jeffbee »

benreesman wrote: post #18

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.

What specifically was your problem with grpc c++ async? I'm using async C++ with one CQ per core and it seems to more or less work.

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

#36

Post by q3k »

sudhirj wrote: post #33
diogenesjunior wrote: post #4

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

If you're communicating between two systems, gRPC has a few benefits: * keeps a socket open between them (HTTP/2) and puts all your method calls on that connection. So you don't have to set up connections on each call or handle your own pooling. * comes with builtin fast (de &)serialization using protobuf. * uses a definition language to generate SDKs for a whole bunch of languages. * makes testing super easy because…

> The auth story isn't very clear. Do you use the out of band setup or add tokens in every single RPC?

I think it's actually quite well documented. [1]

You can have out-of-band authentication data per-connection ('per-channel') and per-RPC ('per-call'). SSL certificates can be used per-connection, while token-based authentication (eg. bearer tokens, or anything else that can fit in metadata) can be either.

[1] https://grpc.io/docs/guides/auth/

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

#37

Post by hagsh »

mradmin wrote: post #32
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…

> You'd use it where you'd use REST/API/JSONRPC/ Not really. You'd use it for inter service communication but can't really use it in the browser (see grpc-web)

At my workplace we use gRPC for inter service and client service communication from a VueJS SPA. It took some effort but is working really great right now. A colleague wrote a blog post (actually entire series) about it: https://stackpulse.com/blog/tech-blog/grpc-web-using-grpc-in...

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

#38

Post by wnevets »

q3k wrote: post #10
diogenesjunior wrote: post #4

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

>Parsing JSON is a Minefield

and there are people who complain it's too simple, i.e no comments

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

#39

Post by sneak »

This thread seems as good a place as any to ask:

Does anyone have experience (good, bad, otherwise) using the gRPC JSON transcoding option for real-world stuff? I'm debating using it (still need REST clients sometimes) but I'm not sure how hacky it is.

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

#40

Post by q3k »

wnevets wrote: post #38
q3k wrote: post #10

Earlier quoted context omitted.

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

>Parsing JSON is a Minefield and there are people who complain it's too simple, i.e no comments

It's one of those 'simple at first glace' standards. If you want to confuse someone who advocates for JSON's 'simplicity' as a feature, ask them what happens when their favorite JSON deserializer receives repeated dictionary keys (yes, that's valid JSON per RFC 7159).
Post reply on HN