51–60 of 99 posts
Earlier quoted context omitted.
Can I ask why you want JSON with gRPC? The benefits to protobuf are tremendous, with little to no downsides
One reason is to be able to call gRPC service from a web browser. Native JSON support makes that much easier.
Earlier quoted context omitted.
Thanks for posting! How did you work around issues with GRPC on AWS/ELB?
We had to stick to layer 4/TCP via an ELB (as opposed to an ALB).
It is nice but would say with limited value outside of Twitch
This looks promising! We use the go-grpc SDK in conjunction with gogoprotobuf, and it's been a rocky road. While the article identifies some operational issues (e.g. the reliance on HTTP/2), there are several considerable deficiencies with gRPC today, at least when using it with Go: 1. The JSON mapping (jsonpb.go) is clumsy at best, and by this I mean that it produces JSON that often doesn't look anything like how yo…
Yeah, I agree with pretty much everything you've written here. > 1. The JSON mapping (jsonpb.go) is clumsy at best The best thing for optional fields in jsonpb is to use the protobuf wrapper types [1]. They have special support in jsonpb to serialize and deserialize as you would expect, without the indirection. But the Go structs you get on the other end are a little weird, so its a tradeoff. > 2. The Go code generat…
Really excited about this. I didn't like how opaque and heavy gRPC is. Also I really wanted support for JSON. Mostly for these reasons, RCP hasn't been implemented in my architecture yet (Just using standard REST) Twirp is everything I wanted in an RPC framework and I'm looking forward to implementing it ASAP. Thanks Twitch team :)
[1] https://cloud.google.com/endpoints/docs/grpc/about-grpc
(Disclaimer: I work on Google Cloud.)
Why use HTTP for transport instead of Messagepack or ZMQ? Seems a bit overkill if you are whipping binary data back and forth between services. Protobuf + ZMQ seems a lot more efficient to me.
Mostly people use HTTP because there are so many services and components that already support it (load balancers, proxies, sidecars etc), it has well-supported options for authentication, conveys metadata seamlessly through multiple layers, and its overhead isn't an issue for the kind of payloads they are sending.
Plus, you know, curl.
It is nice but would say with limited value outside of Twitch
Why use HTTP for transport instead of Messagepack or ZMQ? Seems a bit overkill if you are whipping binary data back and forth between services. Protobuf + ZMQ seems a lot more efficient to me.
A lot of this boils down to wanting to be able to use standard load balancers.
Earlier quoted context omitted.
We had to stick to layer 4/TCP via an ELB (as opposed to an ALB).
gRPC connections are persistent, so a single client will always talk to a single backend in that configuration. It's fine if you have lots of clients but can easily lead to load imbalances. That's why projects such as Envoy exist. I'd link it, but I'm on mobile. Keep an eye on it.
Hey everyone! I'm the OP and primary author of Twirp. I'm happy to answer any questions and hear feedback. You can also reach me directly, if you like, email is in my profile.
Thanks for posting! How did you work around issues with GRPC on AWS/ELB?