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

51–60 of 156 posts

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

#51

Post by benreesman »

jeffbee wrote: post #35
benreesman wrote: post #18

I started a recent project with gRPC but wound up moving to fbthrift after having a bad time with the C++ async server story. Overall I’d like to be using gRPC because the fbthrift documentation is weak, but thread-per-request is a non-starter for some use cases. From the gRPC source it looks like they’ve got plans to do something about it but it seems a ways off.

What specifically was your problem with grpc c++ async? I'm using async C++ with one CQ per core and it seems to more or less work.

It was not obvious to me how to support a large number of methods without a bunch of error-prone boilerplate. It seemed very low-level, which is fine if you have a small number of interactions but it started getting out of hand quickly and fbthrift does this neatly out of the box.

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

#52

Post by thinkharderdev »

fulafel wrote: post #45
weitzj wrote: post #9

Earlier quoted context omitted.

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?

In general, not nearly as mature. In general though, gRPC is not for browser->server calls (grpc-web notwithstanding) but is designed for serverserver communication.

There is some tooling out there for development (https://github.com/fullstorydev/grpcurl and https://github.com/fullstorydev/grpcui are pretty nice) but it's still much less mature than the massive amount of mature tooling available for HTTP-based services. And that is both an artifact of gRPCs relative youth compared to REST and also for some more fundamental reasons (binary wire format, mutual TLS based authentication, etc).

All that said, I've been working with gRPC over the past 6 months or so and overall the development experience is much nicer on net I think.

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

#53

Post by q3k »

fulafel wrote: post #45
weitzj wrote: post #9

Earlier quoted context omitted.

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?

There's grpcurl and other similar tools for when you just want to run a simple gRPC request against a server. If you server runs the reflection service, it will also let you inspect the schema of whatever is running on a given endpoint.

For in-browser use with gRPCweb, if you use test-proto-on-XHR, things continue to work as with REST/JSON.

For inter-server debugging, you usually defer to opentracing or similar, and capture request data there.

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

#54

Post by k__ »

hagsh wrote: post #37
mradmin wrote: post #32

Earlier quoted context omitted.

> You'd use it where you'd use REST/API/JSONRPC/ Not really. You'd use it for inter service communication but can't really use it in the browser (see grpc-web)

At my workplace we use gRPC for inter service and client service communication from a VueJS SPA. It took some effort but is working really great right now. A colleague wrote a blog post (actually entire series) about it: https://stackpulse.com/blog/tech-blog/grpc-web-using-grpc-in...

Does gRPC bring fexibility and discoverability like GraphQL?

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

#55

Post by hagsh »

diogenesjunior wrote: post #4

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

I work in a startup which is ~10 months old where we've decided to go all in on gRPC for all communications, both inter-service and client (Web SPA and a CLI) to service.

Although investment in tooling had been significant in the beginning it has truly paid off its dividends now as we can develop in Golang (micro services, CLI), Javascript (SPA) and Python (end to end testing framework), and have a single definition for all our API endpoints and messages in the form of Protobufs. These protobufs automatically generate all client and server code and give us out-of-the-box backward and forward compatibility, increased performance due to binary format over the wire and more..

Our Architect which put together most of this infrastructure has written an entire series of blog posts about how we use gRPC in practice, detailing our decisions and tooling: https://stackpulse.com/blog/tech-blog/grpc-in-practice-intro...

https://stackpulse.com/blog/tech-blog/grpc-in-practice-direc...

https://stackpulse.com/blog/tech-blog/grpc-web-using-grpc-in...

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

#56

Post by thinkharderdev »

bubersson wrote: post #46
outworlder wrote: post #34

Earlier quoted context omitted.

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

Yeah, one way I've describe gRPC to colleagues (which may help or hurt depending on the perspective) is that is "SOAP, but without all the lunacy"

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

#57

Post by lights0123 »

ForHackernews wrote: post #47
wongarsu wrote: post #21

Earlier quoted context omitted.

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!

Which is at least a very common thing across many fields, not a proprietary Amazon technology.

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

#58

Post by weitzj »

fulafel wrote: post #45
weitzj wrote: post #9

Earlier quoted context omitted.

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?

There is also Charlesproxy which supports Protobuf.

But from my experience you use the code generator and trust the deserializer and serializer since they are unit tested. So you can just unit test your methods and don’t have to look at the actual binary blob payload.

You trust that gRPC is battle tested and you can just test your code.

You would probably wrap the generated methods/objects/structs in your own domain model and unit test the mapping between them. Using the objects from gRPC throughout your code directly does work but sometimes is not what you want to work with.

So I rather would introduce another boundary to the transport. But that is personal preference (in case I want to get rid of gRPC and don’t want to touch my business logic)

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

#59

Post by thinkharderdev »

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.

In many ways comparing REST and gRPC is apples-to-oranges. You can design a gRPC to work according to REST principles, and it is actually generally encourages to do so

And more to the point, the vast majority of "REST APIs" I've experienced in the wild are just RPC-style APIs that use JSON.

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

#60

Post by wbl »

diogenesjunior wrote: post #4

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

When you don't want to deal with the portmapper anymore and think distributed reference counting is a bad idea.

Seriously binary RPC has been around for ages.

Post reply on HN