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

151–156 of 156 posts

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

#151

Post by sneak »

jrockway wrote: post #99
gen220 wrote: post #77

Earlier quoted context omitted.

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

I wrote this authorization code last night: https://github.com/jrockway/jsso2/blob/master/pkg/internalau... Obviously it's quite natural to just add interceptors as you need them and no doubt there are hundreds of things like this across the Internet. To some extent, I can't get over how much of a mess you can make by doing things like this. Because generated service definitions have a fixed schema (func (s Service)…

I assume your Must functions panic. Is panic-ing in a handler considered okay? I was under the impression that using panics as exceptions in this way was un-idiomatic and thus frowned upon.

If it’s the common practice then I’ll happily jump on board, I miss exceptions. I’m just curious because I’m starting to do more web stuff with Go and had been treating handler recovery as something I should endeavor to never touch, as a final guardrail to keep a server process from exiting.

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

#152

Post by apta »

benreesman wrote: post #150
apta wrote: post #141

Earlier quoted context omitted.

Are you bound to C++ for the implementation?

Debatable, latency matters. It’s possible that Rust or a well-tuned JVM could be an alternative, but C++ is a sure thing and schedule matters too.

What's the domain? Financial, or something else out of curiosity?

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

#153

Post by jrockway »

sneak wrote: post #151
jrockway wrote: post #99

Earlier quoted context omitted.

I wrote this authorization code last night: https://github.com/jrockway/jsso2/blob/master/pkg/internalau... Obviously it's quite natural to just add interceptors as you need them and no doubt there are hundreds of things like this across the Internet. To some extent, I can't get over how much of a mess you can make by doing things like this. Because generated service definitions have a fixed schema (func (s Service)…

I assume your Must functions panic. Is panic-ing in a handler considered okay? I was under the impression that using panics as exceptions in this way was un-idiomatic and thus frowned upon. If it’s the common practice then I’ll happily jump on board, I miss exceptions. I’m just curious because I’m starting to do more web stuff with Go and had been treating handler recovery as something I should endeavor to never touc…

Generally I agree with you and tend to avoid writing or calling functions that can panic. I make a slight exception in this case because it will "never" hit the error case; you are "always" calling the RPC through an interceptor that adds the necessary value to the context, so your MustGet functions will "always" work. I use "quotes" around never and always because ... sometimes someone edits the code to delete this invariant, and it is very easy to do that. But, it explodes loudly when it panics, so at least you can go in and fix the problem without much effort. (It would be really insidious to return an error and not check it -- some code three functions deep would then blow up with a nil pointer exception; or to return a subtly-not-working default value that cause subtle broken behavior that's hard to detect. Panics are preferred because the program crashes at the exact line of code that's broken.)

For any case where the error would depend on runtime input, rather than compile-time structure, you should return and check an error. If hitting the error case means "we need to edit the code and release a new version", panic is a fine tool to surface that problem.

All in all, I'd basically be happy either way. If you make your GetFoo function return an error that all the handlers check, I'd approve that PR. If you judiciously panic when something that can "never" happen happens, I'd approve that PR. The obvious preference is to update the codegen to pass those parameters in explicitly, so that if the interceptor structure changes, the program will simply not compile. But, the design of things like net/http and grpc kind of preclude easily doing that, and I'm not sure it's worth the effort to write something on top of those that fix the problem, when it's simple enough to do the unpacking manually and your integration tests test it for free anyway.

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

#154

Post by benreesman »

apta wrote: post #152
benreesman wrote: post #150

Earlier quoted context omitted.

Debatable, latency matters. It’s possible that Rust or a well-tuned JVM could be an alternative, but C++ is a sure thing and schedule matters too.

What's the domain? Financial, or something else out of curiosity?

Financial.

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

#155

Post by sneak »

jrockway wrote: post #153
sneak wrote: post #151

Earlier quoted context omitted.

I assume your Must functions panic. Is panic-ing in a handler considered okay? I was under the impression that using panics as exceptions in this way was un-idiomatic and thus frowned upon. If it’s the common practice then I’ll happily jump on board, I miss exceptions. I’m just curious because I’m starting to do more web stuff with Go and had been treating handler recovery as something I should endeavor to never touc…

Generally I agree with you and tend to avoid writing or calling functions that can panic. I make a slight exception in this case because it will "never" hit the error case; you are "always" calling the RPC through an interceptor that adds the necessary value to the context, so your MustGet functions will "always" work. I use "quotes" around never and always because ... sometimes someone edits the code to delete this…

That’s a wonderful explanation, thank you.

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

#156

Post by BerislavLopac »

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

I wanted to implements gRPC several times but every time ran away due to the terrible state of Python support. It would need a complete rewrite to be remotely usable.
Post reply on HN