Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Twirp: A new RPC framework for Go

blog.twitch.tv

Post reply on HN
Print view View original

41–50 of 99 posts

Re: Twirp: A new RPC framework for Go

#41

Post by grogenaut »

lykr0n wrote: post #36

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.

Absolute throughput or efficiency isn't the goal of most RPC mechanisms, twirp specifically. However I don't think it's underperformant either. It's very easy to reason about, and debug, plays with ELBs well, and most important, gets developers thinking at a Service to Service RPC level instead of about low level stuff.

Fix and optimize throughput for services which actually have those problems.

Re: Twirp: A new RPC framework for Go

#42

Post by grogenaut »

mentat wrote: post #40
lykr0n wrote: post #36

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.

Not just standard load balancers, standard http stacks. Polyglotness is a big benefit here.

Re: Twirp: A new RPC framework for Go

#43

Post by spenczar5 »

anonacct37 wrote: post #39
spenczar5 wrote: post #34

Earlier quoted context omitted.

It's really hard to write benchmarks of an RPC system that mean much, but the overhead is really just in serialization. We have services that handle tens of thousands of requests per second on Twirp in one process. Serialization/deserialization of a typical protobuf struct takes a microsecond or two, but it generates some garbage, so GC ends up slowing you down if you try to go really crazy and push past 100k req/s i…

Thanks, that's the exact info I was looking for. I've unfortunately been bitten before by choosing json as a serialization format, specifically in go, due to JSON performance dominating processing. No criticism though, JSON is the right choice for many types of APIs.

You can and should use Twirp's protobuf serialization instead for almost all applications. The JSON serialization is really intended for developers and low-throughput cross-language clients.

Protobuf serialization isn't free, but it's definitely cheaper than JSON serialization.

Re: Twirp: A new RPC framework for Go

#44

Post by jadeklerk »

warent wrote: post #18

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

Can I ask why you want JSON with gRPC? The benefits to protobuf are tremendous, with little to no downsides

Re: Twirp: A new RPC framework for Go

#45

Post by Xorlev »

justinko wrote: post #22
tschellenbach wrote: post #17

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

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.

Re: Twirp: A new RPC framework for Go

#46

Post by jadeklerk »

lobster_johnson wrote: post #28

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…

You mentioned problems with gRPC, but I think every one of your problems is with protobuf. Is that correct?

Also, regarding point 3, I'm confused with two things:

- You want "free form" data, but you're talking about protos in the context of Go. How would you define this "free form" data in Go?

- You explain that "free form structured data is important for systems that accept foreign data ... where the schema isnt known". Why are you using protobufs for this usecase? Protobufs are specifically meant to make the schema known, and be enforced by serialization.

Re: Twirp: A new RPC framework for Go

#48

Post by johnbellone »

jadeklerk wrote: post #44
warent wrote: post #18

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

Can I ask why you want JSON with gRPC? The benefits to protobuf are tremendous, with little to no downsides

We ran into problems where we had embedded Ruby and Python interpreters (Chef/SaltStack) that made it a big pain to ship new libraries. It was much easier to use the grpc-gateway (HTTP/JSON) for those clients and the generated grpc bindings (HTTP2/proto) for services.

Re: Twirp: A new RPC framework for Go

#49

Post by kjksf »

jadeklerk wrote: post #44
warent wrote: post #18

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

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.

Re: Twirp: A new RPC framework for Go

#50

Post by lobster_johnson »

jadeklerk wrote: post #46
lobster_johnson wrote: post #28

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…

You mentioned problems with gRPC, but I think every one of your problems is with protobuf. Is that correct? Also, regarding point 3, I'm confused with two things: - You want "free form" data, but you're talking about protos in the context of Go. How would you define this "free form" data in Go? - You explain that "free form structured data is important for systems that accept foreign data ... where the schema isnt kn…

True, but gRPC inherits these problems as it's based on Protobuf.

As for free-form data, it should be representable as map[string]interface{}. Our specific use case is a document store that stores documents on behalf of clients. The format of documents cannot be not known by the store, but the API to the store is gRPC. Also, we have a desire for documents to contain higher-level types such as dates, but we're forced to use google.protobuf.Value for this, and treat dates as strings, since Value cannot contain Proto types.

(Our next step is probably to model this explicitly, by defining our own Value message that uses "oneof" to represent all the possible types we need to support, and then using a map of these. But it would be nicer if Protobuf had first-class support.)

Post reply on HN