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

121–130 of 156 posts

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

#121

Post by [deleted] »

q3k wrote: post #107
jwalton wrote: post #95

Earlier quoted context omitted.

In other words, when you want to use ASN.1[0], but you don't know what ASN.1 is so you use something the overly complicated version Google made instead. ;) [0]( https://en.wikipedia.org/wiki/Asn.1 )

How is Protobuf 'overly complicated'? I'm not talking about gRPC here - because trying to compare bare ASN.1 and gRPC is just dishonest. This is especially rich when you're comparing protobuf to ASN.1 - which is probably mostly known for having dozens of competing, obscurely-named encoding formats to choose from. And for them being so complex to implement that it regularly causes bugs and security issues in software.…

[deleted]

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

#122

Post by balfirevic »

hagsh wrote: post #55
diogenesjunior wrote: post #4

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

I work in a startup which is ~10 months old where we've decided to go all in on gRPC for all communications, both inter-service and client (Web SPA and a CLI) to service. Although investment in tooling had been significant in the beginning it has truly paid off its dividends now as we can develop in Golang (micro services, CLI), Javascript (SPA) and Python (end to end testing framework), and have a single definition…

My, oh my! From the first article:

"About 2 months ago I started working at StackPulse. When I joined there was not a single line of code written yet. We’ve had to decide on many different things. One of those things was choosing a “protocol” for communication both between our micro services and externally".

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

#123

Post by halter73 »

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…

The default ASP.NET Core server is Kestrel which runs in-process and is cross platform. Kestrel has officially supported gRPC for over a year now[1]. That linked GitHub comment is specifically about IIS gRPC support which relies on HTTP.sys (which runs in kernel mode and is tied to the Windows shipping cycle as noted).

[1]: https://docs.microsoft.com/en-us/aspnet/core/grpc/?view=aspn...

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

#124

Post by stephenr »

coder543 wrote: post #82
jayd16 wrote: post #80

Earlier quoted context omitted.

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

> These have clearly defined caching and indempotency differences. They are not the same. Clearly defined...? Maybe? I don't know of any popular HTTP proxies that rely on these definitions to automatically decide how to cache things, because people in the real world follow the definitions very loosely. GET is the only one that I've seen relied on, and it's still just a good bet, not a guarantee. Usually, you have to…

I don’t know of any proxy in the wild that will cache anything other than GET or HEAD requests by default.

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

#125

Post by stephenr »

coder543 wrote: post #76
awinder wrote: post #75

Earlier quoted context omitted.

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

the first answer to that question links to the Apache docs, it’s a one line change to add support, possibly with an additional block around it to limit scope to certain urls.

If built in support that works with one config statement isn’t “great” support, what is?

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

#126

Post by jayd16 »

coder543 wrote: post #82
jayd16 wrote: post #80

Earlier quoted context omitted.

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

> These have clearly defined caching and indempotency differences. They are not the same. Clearly defined...? Maybe? I don't know of any popular HTTP proxies that rely on these definitions to automatically decide how to cache things, because people in the real world follow the definitions very loosely. GET is the only one that I've seen relied on, and it's still just a good bet, not a guarantee. Usually, you have to…

>GET is the only one that I've seen relied on

You're so quick to throw away a vastly used caching mechanism as if it's nothing.

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

#127

Post by coder543 »

stephenr wrote: post #125
coder543 wrote: post #76

Earlier quoted context omitted.

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.

the first answer to that question links to the Apache docs, it’s a one line change to add support, possibly with an additional block around it to limit scope to certain urls. If built in support that works with one config statement isn’t “great” support, what is?

It’s not great if you want to use someone else’s API that way to save on egress bandwidth costs... that’s what. They don’t usually let me edit their Apache configs.

Apache being the only thing to support it also wouldn’t count as great. They specifically mentioned uncertainty around nginx. Have you tested any of your APIs to see if they support it?

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

#128

Post by coder543 »

jayd16 wrote: post #126
coder543 wrote: post #82

Earlier quoted context omitted.

> These have clearly defined caching and indempotency differences. They are not the same. Clearly defined...? Maybe? I don't know of any popular HTTP proxies that rely on these definitions to automatically decide how to cache things, because people in the real world follow the definitions very loosely. GET is the only one that I've seen relied on, and it's still just a good bet, not a guarantee. Usually, you have to…

>GET is the only one that I've seen relied on You're so quick to throw away a vastly used caching mechanism as if it's nothing.

GET was never the verb under discussion. I specifically listed PATCH, PUT, and POST as being effectively meaningless in practice. You can’t rely on APIs to do what the verbs say they will do.

I only called out GET to say that it is still only a good bet that it will do what it is supposed to do. It’s absolutely not guaranteed. You’ve never encountered GET web routes that mutate backend state? People rely on it —- but that doesn’t make it reliable.

“Throwing away” verbs like GET is not the same as throwing out caching. Please don’t twist my words into what they were not. In practice, you often still need to specify exactly which routes to cache, and how to cache them. Just using GET doesn’t magically make things cached, and you can just as easily cache non-GET routes once you’re specifying what to cache.

Caching can be done for anything. It isn’t some special feature of HTTP or REST APIs.

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

#129

Post by dragonwriter »

coder543 wrote: post #82
jayd16 wrote: post #80

Earlier quoted context omitted.

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

> These have clearly defined caching and indempotency differences. They are not the same. Clearly defined...? Maybe? I don't know of any popular HTTP proxies that rely on these definitions to automatically decide how to cache things, because people in the real world follow the definitions very loosely. GET is the only one that I've seen relied on, and it's still just a good bet, not a guarantee. Usually, you have to…

> Maybe it's just my bad luck to have encountered all the ways these verbs aren't used consistently over the years.

No, everyone has done that, especially everyone who's encountered almost any non-REST protocol over HTTP, which almost always ignore HTTP semantics (if you're lucky, they tunnel everything over POST.)

But whether other people use the consistently in their APIs is a very different issue than the claim that they are insufficiently clearly defined so that deciding what you should use in implementing an API that respects HTTP semantics (as REST over HTTP should).

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

#130

Post by tybit »

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…

They’ve already folded up shop and solved these problems with Kestrel. Them continuing to offer support for laggards using IIS shouldn’t be criticised though.
Post reply on HN