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

101–110 of 156 posts

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

#101

Post by jwatte »

diogenesjunior wrote: post #4

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

HTTP is super great for loosely coupled, request-based services.

RPC is more lightweight for persistent connections to stateful services. RPC makes broadcast easier than HTTP. Individual RPC requests have (much) less overhead than HTTP requests, which is very helpful when tight coupling is acceptable.

Trying to run, say, MMO gaming servers over HTTP is an exercise in always paying double for everything you want to do. (Also, trying to run a FPS gaming server over TCP instead of UDP is equally not the right choice!)

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

#102

Post by sagarm »

jwalton wrote: post #95
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

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 )

This seems like a very high level spec, not a library or toolkit. There's also zero mention of practical concerns like protocol evolution, a canonical wire encoding etc.

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

#103

Post by corytheboyd »

Maybe I’m crazy, but here is something I have been toying with recently. I have defined services in protobuff and generated static typescript definitions for the services and associated messages. I then implemented my own flavor of RPC over a WebSocket connection, where RPC calls are implemented as two calls— a “start” call from client to server, and a “result” call from server to client. It’s interesting and I don’t know if I would go this far down to the “metal” if you will on a team, but for my own project it’s been interesting.

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

#104

Post by wahern »

jwalton wrote: post #95
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

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 )

To be fair, in practice people don't choose gRPC as a protocol and serialization standard so much as they choose preexisting gRPC libraries and code generators. Open source ASN.1 tooling sucks while Google maintains gRPC tooling for a great many languages. This is why gRPC, Thrift, etc have so much more mindshare than ASN.1 in the open source community. The only good open source ASN.1 (DER, PER, etc) code generator for C is asn1c. I believe Java has a couple of good libraries. But other than that ASN.1 tooling is a horrible train wreck of broken or abandoned projects that don't provide adequate ASN.1 tooling. Many people rely on OpenSSL's DER library, but its far too low-level. AFAICT, the same is true for Python and other high-level languages--no open source projects where can you pass an ASN.1 specification to generate (at compile-time or run-time) a full serializer and deserializer.

There are plenty of commercial, proprietary ASN.1 tooling solutions out there. Presumably it's why ASN.1 has persisted as long as it has in industry. Even Fabrice Bellard sells a commercial solution: https://bellard.org/ffasn1/ When you have access to good tooling ASN.1 is arguably superior to the open source alternatives as there aren't as many broken corner cases that can cause interoperability problems.

We only have ourselves to blame. If I ever have time I want to write an ASN.1 spec parser using LPeg that can generate LPeg-based DER parsers. I already have a fairly comprehensive LPeg-based DER parser for PKIX messages, but generating that from an ASN.1 spec is a significant step up in conceptual complexity. While I've written more than my fair share of parsers before, I've never written a proper parser generator, so it's a steeper hill to climb for me even though I already have more ASN.1 experience than most.

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

#105

Post by dragonwriter »

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

HTTP verbs. REST is a protocol-neutral architectural style (of which HTTP is an implementation), it doesn't have verbs.

> that is often super arbitrary. PUT vs POST vs PATCH...

They aren't arbitrary, they have well-defined semantic differences. It's true that “REST” APIs built over HTTP often play fast and loose with HTTP semantics, but that's not a feature of REST so much as people understanding neither REST not HTTP.

> HTTP response codes... so many numbers, so little meaning!

HTTP Status Codes have very well defined meanings.

> Response codes other than 200 and 500 are effectively never good enough by themselves, so then we come to the next part

201, 202, 204, 3xx, 4xx, and 5xx are usually fine alone, though sometimes it's nice to augment 4xx/5xx with additional info.

200, on the other hand, usually needs more info unless it's being used in a case where 201/204 would be more specific.

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

#106

Post by Saser »

weitzj wrote: post #97
bwarren2 wrote: post #94

Does anyone have a favorite intro/guide/book on gRPC? I have been wanting to learn for a while.

grpc.io is great to start learning. Also the blog posts on grpc.io are interesting, but I find them harder to discover whilst reading the documentation. But here they are: https://grpc.io/blog/ Grasping the concept of a context/deadlines is quite helpful: https://grpc.io/blog/deadlines/ You could also find related information in the Google SRE Handbook (Service Level Objectives): https://landing.google.com/sre/sre-bo…

In addition to these, I think that Google's API Design Guide (https://cloud.google.com/apis/design) and their AIPs (https://aip.dev) are good references for learning about how their style of APIs, called resource-oriented APIs, can be designed. There is a linter that can check whether an API follows the AIPs (I know, these acronyms are easy to mix up), available at https://linter.aip.dev. I am building a side project following the AIPs and have found them to be very helpful.

Disclaimer: I work at Google, although I would have recommended these resources anyway.

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

#107

Post by q3k »

jwalton wrote: post #95
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

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

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

#108

Post by sharx »

dragonwriter wrote: post #105
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 HTTP verbs. REST is a protocol-neutral architectural style (of which HTTP is an implementation), it doesn't have verbs. > that is often super arbitrary. PUT vs POST vs PATCH... They aren't arbitrary, they have well-defined semantic differences. It's true that “REST” APIs built over HTTP often play fast and loose with HTTP semantics, but that's not a feature of REST so much as people under…

Re: the verbs, gRPC is built on top of HTTP, and does not use the verbs (it's always POST). So I think it was fair to call them "REST verbs" in this context.

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

#109

Post by foota »

corytheboyd wrote: post #103

Maybe I’m crazy, but here is something I have been toying with recently. I have defined services in protobuff and generated static typescript definitions for the services and associated messages. I then implemented my own flavor of RPC over a WebSocket connection, where RPC calls are implemented as two calls— a “start” call from client to server, and a “result” call from server to client. It’s interesting and I don’t…

I'd be curious, how do you handle associating rpc responses from the server with the request call site? Some sort of id?

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

#110

Post by e12e »

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.

> I had the impression RPC was seen as a mistake.

For hypermedia/hypertext Fielding made a solid argument for preferring REST over RPC (mostly because of caching). I still recommend reading his very approachable thesis - these days not so much for the web/REST architecture, but for the other ones, which include modern SPAs (they're not great as hypermedia apps, but fine as networked applications):

https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

Apart from caching (and cache invalidation) it's accepted that making the network invisible is a bad idea - it will lead to issues. So remote procedure calls aren't inherently bad, but blurring the distinction too much between local procedure calls and remote ones aren't a great idea. From hung nfs mounts to unpredictable application performance, it is unpleasant.

This Netflix talk on their not-graphql framework gives a very nice summary of when and how you might prefer RPC to REST:

https://youtu.be/hOE6nVVr14c

Post reply on HN