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

71–80 of 156 posts

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

#71

Post by coder543 »

Guthur wrote: post #69
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...…

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 i…

I'm not saying they're hard questions. They're annoying, pointless questions that I have to answer every single time I create or consume a REST API. Those pointless questions also create very real bugs that I have dealt with for years, because humans make mistakes.

It's a complete waste of time and energy for everyone involved. Every one of these questions creates additional mental overhead and an opportunity for incorrect implementation. I would rather deal with meaningful decisions as often as possible, like questions of state management, instead of constantly deciding what color to paint the bike shed based on each person's interpretation of what "the most RESTy" API should look like.

You didn't seem to disagree with me in any way... I see nowhere in your comment where you say that REST APIs are better than gRPC, or why you would pick to make a REST API over gRPC or vice versa. Your rant just has nothing to do with my comment, as far as I can tell?

I never claimed that `gRPC` would solve state management. I never even mentioned state management.

So... cool? gRPC is not a magic bullet, I completely agree. It's a tool, and it seems to have advantages over REST APIs. That's what we're discussing here, since the OP asked why someone would use gRPC.

Your comment seems to imply that it's pointless to improve one problematic situation (RPC) without completely fixing all other problems in existence.

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

#72

Post by q3k »

Guthur wrote: post #69
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...…

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 i…

Sure, gRPC is no magic bullet that will solve all issues across your stack, but it is still a very solid tool/library. Using it instead of REST allows you quickly solve the easy problems (sending typed messages across the wire) while letting you focus on the hard parts (building distributed systems).

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

#73

Post by gen220 »

jeffbee wrote: post #68
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.

Depending on your perspective, though, this can be seen as a positive thing: gRPC is extensible enough that all of this can be built on top.

I'm sure that in 10 years, there will be more concepts like "trace IDs" that we will consider minimally necessary for distributed service architectures, that don't exist today.

FWIW, writing the libs to do the metadata injection/extraction is pretty straightforward and transparent to application developers if they're done right.

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

#74

Post by llimllib »

gen220 wrote: post #73
jeffbee wrote: post #68

Earlier quoted context omitted.

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.

Depending on your perspective, though, this can be seen as a positive thing: gRPC is extensible enough that all of this can be built on top. I'm sure that in 10 years, there will be more concepts like "trace IDs" that we will consider minimally necessary for distributed service architectures, that don't exist today. FWIW, writing the libs to do the metadata injection/extraction is pretty straightforward and transpare…

Here's my real-world grpc request ID propagation middleware in go, it's extremely simple: https://gist.github.com/llimllib/d0840eaee14411a50201960615d...

this function gets called a couple hundred million times per week, and has never failed as far as I know

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

#75

Post by awinder »

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

"HTTP servers will often support compressing the response, but almost never do they allow compressing the request body"

What doesn't have great support for Content-Encoding headers?

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

#76

Post by coder543 »

awinder wrote: post #75
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...…

"HTTP servers will often support compressing the response, but almost never do they allow compressing the request body" What doesn't have great support for Content-Encoding headers?

What does have great support? Content-Encoding works great from server -> client, but not the other way around, in my experience. That's the problem I'm discussing. It's theoretically possible to support.

See this stackoverflow question for one brief discussion: https://stackoverflow.com/q/20507007

I've looked around for this feature and rarely found it to be supported... but it's also rarely discussed.

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

#77

Post by gen220 »

llimllib wrote: post #74
gen220 wrote: post #73

Earlier quoted context omitted.

Depending on your perspective, though, this can be seen as a positive thing: gRPC is extensible enough that all of this can be built on top. I'm sure that in 10 years, there will be more concepts like "trace IDs" that we will consider minimally necessary for distributed service architectures, that don't exist today. FWIW, writing the libs to do the metadata injection/extraction is pretty straightforward and transpare…

Here's my real-world grpc request ID propagation middleware in go, it's extremely simple: https://gist.github.com/llimllib/d0840eaee14411a50201960615d... this function gets called a couple hundred million times per week, and has never failed as far as I know

Yep! The internal libs at our company look very very similar.

You can also do fun middleware things like rate limiting and ACLs, but I haven't seen those in the wild.

If somebody has links to examples those, please share. :)

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

#78

Post by ComputerGuru »

muststopmyths wrote: post #29
lvice wrote: post #2

I find interesting the discussion regarding gRPC support for Azure App Service, and the amount of moving parts involved to achieve such support... https://github.com/dotnet/aspnetcore/issues/9020#issuecommen...

Really illustrates the dumbassery of sticking a (relatively) fast-moving application-layer protocol into the kernel. Now you can't update the Web Server without updating the operating system. Might have been handy to beat benchmarks back in the day when people liked to whip them out for comparison, but IIS is under 10% according to Netcraft now. Time to fold up the tent and go home. I suppose .Net Core is sticking wi…

> Really illustrates the dumbassery of sticking a (relatively) fast-moving application-layer protocol into the kernel.

Really? There are lots of problems with doing HTTP in the kernel, but “fast moving” is a new one. HTTP was stuck in permafrost from 1995 to 2015. If it weren’t for Google, neither of HTTP 2 or 3 would have ever happened.

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

#79

Post by jeffbee »

gen220 wrote: post #73
jeffbee wrote: post #68

Earlier quoted context omitted.

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.

Depending on your perspective, though, this can be seen as a positive thing: gRPC is extensible enough that all of this can be built on top. I'm sure that in 10 years, there will be more concepts like "trace IDs" that we will consider minimally necessary for distributed service architectures, that don't exist today. FWIW, writing the libs to do the metadata injection/extraction is pretty straightforward and transpare…

There's always two sides to extensibility. One the one hand, you have the opportunity to do it your way. On the other, you have to do it. The extreme of extensibility is always an empty file. You get to pick the language and the architecture and everything!

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

#80

Post by jayd16 »

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

>- There's also the REST verb that is often super arbitrary. PUT vs POST vs PATCH... so many ways to do the same thing.

These have clearly defined caching and indempotency differences. They are not the same. I don't believe gRPC handles this or it looks like its experimental.

Post reply on HN