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

61–70 of 156 posts

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

#61

Post by malkia »

Used stubby at Google (mainly java), and was intimidated first, then saw the light - when almost everything uses the same way of talking, not only you get C++, java, python, go and other languages speaking freely to each other, but other extra benefits - for example each RPC can carry as a "tag" (key/value?) the user/group it came from, and this can be used for budgeting:

For example - your internal backend A, calls service B, which then calls some other service C - so it's easy to log that A called B, but the fact that C was called because of what A asked is not, though if propagated (through the tag) then C can report - well I was called by B, but that was on on A to pay.

Then dapper, their distributed tracing was helpful in the few times I had to deal with oncall (actually them asking me to do it). And in general, it felt like you don't have to write any low-level sockets code (which I love)

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

#62

Post by mnd999 »

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.

RPC is apparently en vogue again. Everything new is old.

It’s a pretty decent implementation of the pattern though. Efficient binary protocol (unlike SOAP), built in security and none one of the complexity of object request brokers. Although you might actually want that and you’ll likely end up with something complex like Istio.

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

#63

Post by coder543 »

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…

If you want the list items to render on separate lines, you need to either add an extra newline between list items, or indent the list items by 4 spaces.

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

#65

Post by hagsh »

k__ wrote: post #54
hagsh wrote: post #37

Earlier quoted context omitted.

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

Does gRPC bring fexibility and discoverability like GraphQL?

I have not used GraphQL in practice so I can't directly compare them.

What I can say is that in terms of flexibility, protobufs by nature provide us with forward and backward compatibility. We can easily add new fields and eventually deprecate old ones, evolving the API similarly to GraphQL.

Apparently, gRPC also has some introspection capabilities like GraphQL (since again you have a clear protobuf schema) but I have never used them in my clients, and perhaps they are not as baked into the system as in GraphQL.

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

#66

Post by malkia »

k__ wrote: post #54
hagsh wrote: post #37

Earlier quoted context omitted.

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

Does gRPC bring fexibility and discoverability like GraphQL?

You can enable reflection API (but must compile your server with it) - e.g. it exposes some well known end-point, which when asked can return you back the other end-points available (services), and then asking each end-point service can return each method - and then for each method - what it takes (assuming as "proto") and returns, also what kind is (one shot, bidi, etc.)

So not the same as GraphQL, as you are not asking about resources/objects, but rather inspecting what can be called and how.

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

#67

Post by spockz »

kbar13 wrote: post #43
coder543 wrote: post #26

Earlier quoted context omitted.

Things I "love" about REST APIs: - How should I pass an argument? Let me count the many ways: 1. Path parameters 2. Query parameters in the URL 3. Query parameters in the body of the request 4. JSON/YAML/etc. in the body of the request 5. Request headers (yes, people use these for API tokens, API versions, and other things sometimes) - There's also the REST verb that is often super arbitrary. PUT vs POST vs PATCH...…

Also writing bespoke REST clients for every single endpoint is just a huge waste of time and error prone since there’s so many ways of doing everything. One of my biggest gripes with REST APIs is having identifiers in url path instead of in query params or the request body

Honestly, swagger and OpenApi have existed for ages. Who still creates bespoke rest clients? It took me one day to create a template for generating code that links our http client of choice to api specifications. These also exist out of the box for many clients like ribbon.

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

#68

Post by jeffbee »

malkia wrote: post #61

Used stubby at Google (mainly java), and was intimidated first, then saw the light - when almost everything uses the same way of talking, not only you get C++, java, python, go and other languages speaking freely to each other, but other extra benefits - for example each RPC can carry as a "tag" (key/value?) the user/group it came from, and this can be used for budgeting: For example - your internal backend A, calls…

Unfortch, gRPC brings none of these things. If you want delegated caller, originator, trace ID, or any other kind of baggage propagated down your RPC call graph, you are doing it yourself with metadata injectors and extractors at every service boundary.

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

#69

Post by Guthur »

coder543 wrote: post #26
diogenesjunior wrote: post #4

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

Things I "love" about REST APIs: - How should I pass an argument? Let me count the many ways: 1. Path parameters 2. Query parameters in the URL 3. Query parameters in the body of the request 4. JSON/YAML/etc. in the body of the request 5. Request headers (yes, people use these for API tokens, API versions, and other things sometimes) - There's also the REST verb that is often super arbitrary. PUT vs POST vs PATCH...…

Because all those questions are the easy ones.

gRPC is not a magic bullet for the problems of state management. It'll have all the same issues RPC has had for the last 30 years in that it enforces no discipline where it counts, state management.

The real problem with REST is that state management across a distributed system is hard, real hard. So hard actually that we decide to ignore that it's a problem at all and instead get obsessed with client side interface code, transport protocol, or content types etc, the easy mechanical stuff.

gRPC wont be a magic bullet, just like CORBA wasn't, or XML-RPC, or SOAP. History does like to repeat itself...

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

#70

Post by mrkurt »

weitzj wrote: post #13

So the only remaining question is: When does AWS roll out quic support in ALBs?

(Disclaimer: I work on Fly.io, this post is bias)

It will probably be a while. We've been evaluating Quic and the ecosystem just isn't quite ready. We opted to release UDP support instead, so apps that want Quic can do it, but we can avoid adding much extra plumbing in front of the simple HTTP apps.

Given how much AWS is investing in Rust, they'll probably ship first class support for Quic when Hyper does (same as us!): https://github.com/hyperium/hyper/issues/2078

Post reply on HN