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

81–90 of 156 posts

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

#81

Post by deckard1 »

q3k wrote: post #40
wnevets wrote: post #38

Earlier quoted context omitted.

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

there is no standard so simple that humans won't make a mess of it. You think "CSV, comma-separated-values, it's right in the name!" And then you write a parser for it and realize it won't read CSV files Excel generates.

Years ago I was porting an r5rs Scheme app from Guile to other Scheme systems. The entire standard is 50 pages of fairly readable basic English. You would not believe the amount of differences different interpreter/compilers have on their agreement as to what a symbol can be. Or under-specified cases such as integer->char (one system goes out of its way to be a dick about it and purposely not use ASCII, trading pragmatics for pedantry)

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

#82

Post by coder543 »

jayd16 wrote: post #80
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...…

>- 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 define which routes are cacheable and carefully configure the cache settings... in my experience, at least.

Maybe it's just my bad luck to have encountered all the ways these verbs aren't used consistently over the years. They're a hint towards what will happen... at best. In my experience, anything goes, no matter what the verb says.

I truly hope you've had a better experience, and that it's just me.

> I don't believe gRPC handles this or it looks like its experimental.

Which seems fine. We can't rely on HTTP verbs for state management because of how inconsistent implementations are, so I don't expect gRPC to do that either, but at least gRPC won't make you choose a random verb.

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

#84

Post by Guthur »

coder543 wrote: post #71
Guthur wrote: post #69

Earlier quoted context omitted.

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

If you're working in a group think conformist organisation with a single mono repo like Goolge then gRPC certainly has some allure.

But if I'd like to remain a little more decoupled it's not very good at all.

REST is definitely not a magic bullet either because more often than not we fail to do that hard modelling aspect well enough.

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

#85

Post by jeffbee »

q3k wrote: post #40
wnevets wrote: post #38

Earlier quoted context omitted.

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

  % echo '{"a": 5, "a": 42}' | jq  
  {
    "a": 42
  }
Pretty much what I expected and also what you would get if you saw two instances of the same optional non-repeated field in a protocol buffer message. What were you expecting or wanting?

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

#87

Post by malkia »

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.

I've only used grpc for C# talking to C++ and wanted to plug this in, saw other users posting about injectors - so gonna look into it :) - I really want to avoid yet another proxy/"service-mesh" process for something that could be done on the client side (I wish I could inject the http2 library to propagate this always with headers somehow, but it's not a single thing, also too low level for me - Tools/app developer pretty much)

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

#88

Post by Groxx »

jeffbee wrote: post #85
q3k wrote: post #40

Earlier quoted context omitted.

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

% echo '{"a": 5, "a": 42}' | jq { "a": 42 } Pretty much what I expected and also what you would get if you saw two instances of the same optional non-repeated field in a protocol buffer message. What were you expecting or wanting?

Their point was likely that implementations vary on the interpretation. Which is a bit of a problem for rpc systems.

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

#89

Post by coder543 »

Guthur wrote: post #84
coder543 wrote: post #71

Earlier quoted context omitted.

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

If you're working in a group think conformist organisation with a single mono repo like Goolge then gRPC certainly has some allure. But if I'd like to remain a little more decoupled it's not very good at all. REST is definitely not a magic bullet either because more often than not we fail to do that hard modelling aspect well enough.

> But if I'd like to remain a little more decoupled it's not very good at all.

I don't really understand how gRPC makes this harder.

Either way, you have to call things correctly or they don't work. gRPC just naturally generates the client implementation for you, and it should always work. Swagger/OpenAPI theoretically help with this on the REST side of things, but it's up to the person publishing the Swagger as to whether it is actually 100% correct, or just a first order approximation.

But, I agree it's easier to have one protocol than two inside a company, so that would definitely be a downside of having both REST and gRPC in one organization.

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

#90

Post by q3k »

jeffbee wrote: post #85
q3k wrote: post #40

Earlier quoted context omitted.

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

% echo '{"a": 5, "a": 42}' | jq { "a": 42 } Pretty much what I expected and also what you would get if you saw two instances of the same optional non-repeated field in a protocol buffer message. What were you expecting or wanting?

Here's the kicker: while this might sensible to you, some JSON implementations out there will reject duplicate fields (fail a parse completely), and the RFC does not even specify what is the correct behavior (override previous, ignore duplicates, fail entire parse, return non-unique keyed dictionary, something else entirely?).

So while to you and I this behavior might be expected (although I'm still not sure that overriding previous fields is more obvious than ignoring repeated fields) - some library implements thought differently, and there isn't even an agreed on standard. Arguing about this isn't purely academic, either - there have been security vulnerabilities resulting from these differences [1].

[1] - https://justi.cz/security/2017/11/14/couchdb-rce-npm.html

Post reply on HN