I'm just going to jump in with an utterly pointless "woohoo!" As a gRPC shop, this is going to open up a lot of options for both our own infra and make it easier to support clients on AWS. Now if only Azure would make it easy to implement solutions that leverage gRPC...
Application Load Balancers enables gRPC workloads with end to end HTTP/2 support
41–50 of 156 posts
Re: Application Load Balancers enables gRPC workloads with end to end HTTP/2 support
#42This thread seems as good a place as any to ask: Does anyone have experience (good, bad, otherwise) using the gRPC JSON transcoding option for real-world stuff? I'm debating using it (still need REST clients sometimes) but I'm not sure how hacky it is.
It probably varies by the language and library but for java it has been flawless. I wouldn’t expect many issues for any major language.
Re: Application Load Balancers enables gRPC workloads with end to end HTTP/2 support
#43Can 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...…
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
Re: Application Load Balancers enables gRPC workloads with end to end HTTP/2 support
#44Half-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.
gRPC is not necessarily binary. It is often conflated with protobuf but it is in fact payload format agnostic. You can run it with JSON payloads if you want.
Re: Application Load Balancers enables gRPC workloads with end to end HTTP/2 support
#45Can somebody please explain to me why we would use gRPC?
It makes it really nice to define APIs (like with Openapi of swagger). There is a bunch of code generators out there to produce code for your definitions to have a native swift , objective , Java, Go api stubs for either clients or servers. It is a joy to work with in cross functional teams and define your APIs whilst taking into account what Api versioning would mean, how to define enums, how to rename field names w…
Not familiar with gRPC, questions: how does the tooling compare to HTTP? Browser devtools lets you look what's on the wire, replay requests with slight alterations for debugging, have timelines and visualizations for the history of communication, extract and send self contained scriptlets (like you can do with curl) to someone else, etc. Which of these have some equivalents in generally available gRPC tooling?
Re: Application Load Balancers enables gRPC workloads with end to end HTTP/2 support
#46Earlier quoted context omitted.
it's use case is companies that want to use SOAP but don't want to say they use SOAP
How is it related to SOAP in any way?
I'm not OP, but the main parallel is a well defined schema of communication between the services using different underlying technologies.
SOAP is in my experience really hard to use and get right, compared to protobufs that bring well understandable set of primitives and intuitive support in many languages. gRPC is a solid carrier for protobufs. Yes, gRPC has many cons (e.g. with undefined/nil values, etc.), but overall it has worked great for our usecases.
Re: Application Load Balancers enables gRPC workloads with end to end HTTP/2 support
#47AWS, ALB, gRPC - it seems one needs to swallow a thesaurus to communicate these days.
AWS is suffering from a TLA problem. gRPC on the other hand is a decent name, at least you can guess at a glance that is a RPC protocol. Meanwhile you just have to know that ALB is a type of ELB.
...only if you know what "RPC" means!
Re: Application Load Balancers enables gRPC workloads with end to end HTTP/2 support
#48This thread seems as good a place as any to ask: Does anyone have experience (good, bad, otherwise) using the gRPC JSON transcoding option for real-world stuff? I'm debating using it (still need REST clients sometimes) but I'm not sure how hacky it is.
We use it. It's pretty good. It has a lot of places you can hook in extra functionality. You get most of the HTTP error status codes for free, but we also have a filter that looks at outgoing protobuf messages for a certain field that indicates the messages is a response to a create request, and that allows us to return an HTTP 202 instead of 200. We were even able to do Amazon-style request signing. One thing about request signing is that if you use protobuf key-value maps, the order is not deterministic on the wire. This broke our signing. Key-value maps are kind of a protobuf hack anyway, so we ended up using an array of structs. When it came time to add the JSON gateway, we found it pretty easy to write custom JSON serialization/deserialization code to convert the structs to a JSON map. This is all in Go by the way.
Re: Application Load Balancers enables gRPC workloads with end to end HTTP/2 support
#49This thread seems as good a place as any to ask: Does anyone have experience (good, bad, otherwise) using the gRPC JSON transcoding option for real-world stuff? I'm debating using it (still need REST clients sometimes) but I'm not sure how hacky it is.
The grpc Gateway in Go worked quite well for us.
I have not tried the native Envoy decoding functionality, yet.
Also you should look at Google Artman on github/googleapis as sometimes it felt that defining the REST mappings in Protobuf were lacking some features. Using google artman you kind of mix/match Protobuf with yaml definitions of your service.
We never had to use it, though. It just depends on where you want to put your authentication information. As of today I would probably change my mind and make it explicitly in payload, I.e. Protobuf message and not fiddle with headers any more.
Re: Application Load Balancers enables gRPC workloads with end to end HTTP/2 support
#50So the only remaining question is: When does AWS roll out quic support in ALBs?
If it's anything like HTTP/2, in 4-5 years.