Live data from Hacker News

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

aws.amazon.com

91–100 of 156 posts

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

#91
post #73
post #68

Earlier quoted context omitted.

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.

Depending on your perspective, though, this can be seen as a positive thing: gRPC is extensible enough that all of this can be built on top. I'm sure that in 10 years, there will be more concepts like "trace IDs" that we will consider minimally necessary for distributed service architectures, that don't exist today. FWIW, writing the libs to do the metadata injection/extraction is pretty straightforward and transpare…

Yeah, I think you just need to invest a small amount of time to set up your clients and servers, and you reap the benefits for a long time.

I use https://github.com/jrockway/opinionated-server as the foundation of my server-side apps. I thought about monitoring, tracing, and logging once... and then get it for free in every subsequent project. I explode the app into my cluster, and traces are immediately available in Jaeger, I can read/analyze my logs, and it's all a pleasure to debug. I think everyone should just have their own thing like this, because it's definitely a pain to do it more than once, but a joy once you have it working.

(My thing specifically is missing some things I now need, though, like multiple loggers so you can turn on/off rpc tracing at runtime, support for auto-refreshing TLS certs from a volume mount now that everything is mTLS, etc. Will be added when I am less lazy ;)

While I'm here I'll also plug https://github.com/jrockway/json-logs for making the structured logs enjoyable to read. You can query them with jq, it understands all the popular JSON log formats, and I can't live without it. It's the only client-side app I've ever written that passes the "toothbrush test" -- I use it twice a day, everyday. Recommended ;) (Someday I will write docs and an automated release process.)

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

#93
post #69

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

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…

> gRPC wont be a magic bullet, just like CORBA wasn't, or XML-RPC, or SOAP. History does like to repeat itself...

I will commend gRPC for being brave enough to attach "RPC" to its name in 2020. Can't say the same for that quisling GraphQL, which is neither what I would call a query language nor has anything to do with graphs. A- for marketing effort, I suppose.

> it enforces no discipline where it counts, state management

A tale as old as time. If your redux app is a bloated confusing mess, then try scaling down your department from 100 devs to the 10 that it actually needs. Most devs are bad at organization. Most devs are just bad in general. Ever see a bad developer grapple with TypeScript? I wager most codebases fall apart from disarray long before they reap any of the presumed benefits of most "best" practices. You can't fix social problems with technology. And code hygiene and state hygiene are fundamentally social issues. People think tools like Prettier can come around and clean their house for them. Like some Roomba for code. Even the best Roomba will smear dog shit all over the place.

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

#95
post #10

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

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)

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

#96
post #90
post #85

Earlier quoted context omitted.

% 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 ove…

Interesting. Protobuf specifies this last-instance-wins behavior, and it can be pretty useful. It allows you to override a field by simply appending a few bytes, without having to re-encode a whole message. JSON I guess doesn't have as much concern for efficiency as protobuf has.

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

#97

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-book/chapters/service-lev...

If you are familiar with Go, the article about "Context" might also be helpful: https://blog.golang.org/context

But in any case, gRPC is language agnostic and has nothing to do with Go.

To get an idea how to create an api-repository with protobuf defintions to be shared by multiple services/clients, one can look at: https://github.com/googleapis/googleapis

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

#98
post #97

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…

Thank you!!

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

#99
post #77

Earlier quoted context omitted.

Here's my real-world grpc request ID propagation middleware in go, it's extremely simple: https://gist.github.com/llimllib/d0840eaee14411a50201960615d... this function gets called a couple hundred million times per week, and has never failed as far as I know

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) Method(context.Context, Request) (Reply, error)), you have to resort to hacks like propagating the current user through the context, instead of the easy-to-read and easy-to-test alternative of just passing in the parameters explicitly, as in func (s Service) Method(context.Context, types.Session, Request) (Reply, error). If I was going to spend time on infrastructure, that's the thing I'd fix first.

Some other frameworks do a little better here. We use GraphQL at work, and the methods are typically of the pattern:

    func AutogeneratedMethod(context.Context, ...) {
       foo := MustGetFoo(ctx)
       bar := MustGetBar(ctx)
       return ActualThingThatDoesTheWork(ctx, foo, bar, ...)
    }
This makes testing the Actual Thing That Does The Work easier, and the reader of that method knows exactly what sort of state the result depends on (the most important goal in my opinion).

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

#100
post #22

Earlier quoted context omitted.

> I had the impression RPC was seen as a mistake. Aren't REST and webhooks just RPC protocols too?

Are they? I thought the difference is, that RPC hides behind a function that looks like it would behave like it was local, but in fact does a remote call and REST explicitly states that things happen remote.

REST is centered on resources (nouns), RPC is centered on procedures (verbs). REST is more constrained.

A Remote Procedure is just that, a procedure. Procedures don't have many constraints. They can implicitly change the state of resources on the server. They can do whatever you want.

REST APIs are supposed to be designed around state transfer. You transfer the state of a resource from server to client with a GET. You transfer the state back to the server with a POST/PUT. The operations are supposed to be 'stateless' in that the result is not supposed to depend on the pre-existing state of the resource on the server.

To give a silly example, let's say I have a Counter service. In RPC I could expose a incrementByOne procedure. And then clients could just call:

    incrementByOne(id=1)
In REST I would have a Counter resource. The RESTful way to increment the counter would be:

    GET /api/counter/1
    -> OK {'id': 1, 'value': 12}

    PUT /api/counter/1 {'id': 1, 'value': 13}
    -> OK
It's more cumbersome, but notice that unlike the RPC call, the result of the PUT request doesn't depend on the current state in the server. The counter will always end up at 13. The PUT request is idempotent, I can repeat it n times and end up with the same result. Obviously that's not true with the RPC call. Notice also that the client must implement its own logic for incrementing.

You could design a RESTful RPC, where the only methods are like:

    getCounter(id) -> Counter

    createCounter(Counter) -> id

    putCounter(Counter)
The opposite, RPC over REST, doesn't really work. I guess you could try representing procedures as resources but it would be incredibly awkward. That's why I say REST is more constrained.

With well designed REST you should end up with very decoupled logic between server and client since all they can do is transfer state, they each have they wholly separate logic to deal with the state.

With RPC you can end up with some real spaghetti, where the logic of client and server are intertwined. But not everything can be modeled cleanly as resources, sometimes you really do just want to execute some logic on the server.

Post reply on HN