4 ms·

I work in a small shop, much "behind the times", and recently tried introducing gRPC. It went okay. The problem is it was a hard sell and for our limited needs,

I work in a small shop, much "behind the times", and recently tried introducing gRPC. It went okay. The problem is it was a hard sell and for our limited needs, a lot of gRPC's features weren't something we didn't happily solve with REST. Some of the other more complex features that REST didn't support were things we didn't feel we needed. All together, gRPC was a big burden for me to push, with little payoff for people. I think I was the only one that liked it, and even I disliked parts of it. So before pulling the switch too far, I decided to take a step back and assess with benefits we all got from gRPC. Mainly it was Protobuf spec, RPC design (ie not REST verbs and whatnot), and code generation. Because those were the things we all agreed upon, I went with Twirp[0]. It's been a great experience so far. The rollout is just a bit ahead of where our gRPC was, and it's been mostly effortless. The most effortless thing? I've got an (internal) API user switching from the old REST API to the proto RPC spec, and all they're changing is the URL and a few field naming schemes. It's still JSON for them. They're not generating code, they're not doing anything. It all "just works", which is pretty impressive. TL;DR: We love simpler options that let us gain the benefits of Protobufs, without the complexity of gRPC when we don't need it. [0]: https://blog.twitch.tv/twirp-a-sweet-new-rpc-framework-for-go-5f2febbf35f https://blog.twitch.tv/twirp-a-sweet-new-rpc-framework-for-g...

nzoschke 8y ago
OP here. Agree completely that .proto offers big advantages on its own. Also agree that grpc is complex and challenging. We considered twirp too. A few things that pushed us towards gRPC... Canonical error codes and semantics. Standards here go such a long way to building reliable systems. The ecosystem. There are a lot of middlewares, validators, transcoders written specifically for the Go gRPC stack. Envoy. This has a lot of things we wanted like rate limiting and auth which are implemented over gRPC. With AWS adopting Envoy for their service mesh offering it’s a safe technology bet now. Performance. This doesn’t matter for our API stack but could be a huge gain in Segments data plane. That said I still wish all this was simpler. Twirp looks like a great choice in that regard.
grpcthrowa1215 8y ago
I work on GRPC. Twirp is serious competitor to GRPC due to being easier to use (as you noticed) and gets most of the benefits just by using Protobuf. It's a problem for us because it's hard to explain the value added. For me, the reason to use GRPC is because there is a very good story about the boring details of networking. The stuff that would make other programmers eyes glaze over but are nonetheless important, has basically been solved by GRPC. What happens when the connection gets dropped but you haven't sent the RPC yet? Does it try to find another server to send it to? Does it time out? What happens if the DNS entries change after you connect? Does it even use all the addresses that DNS returned? If the connection has been idle for for 30 minutes, does it keep it around or shut it down? How does it even know if the connection is good after being idle so long? Home routers have a bad habit of breaking connections due to their NAT. For most of these problems, TCP and UDP only gives you the tools to solve them, but don't do so out of the box. Coming back to Twirp, I don't recall seeing these things addressed in their code, (except what Go's net and http library already provide). If you don't care about those networking details (and it's completely legitimate if you don't, some people don't need to), then I think Twirp's API is much more pleasant to use, and still gets you 80% of the benefit of GRPC.
- Game_Ender 8y ago
  Is the GRPC API less pleasant because you have to handle those details? Or could it be evolved to be more user friendly?
- justicezyx 8y ago
  Grpc is the enterprise ready and high-performance rpc infrastructure, I cannot believe Google still cannot figure out the right pitch. There isn't anything in the world that can match grpcs features and still perform at the same level, plus Google's decades of large scale use. Guys, I am so disappointed at how Google push it's internal technology. People won't come to you without pitching, be smart...
  - hsaliak 8y ago
    PM for gRPC here. Feedback received! :) What would you like to see us do more of?

nzoschke 8y ago

OP here. Agree completely that .proto offers big advantages on its own. Also agree that grpc is complex and challenging. We considered twirp too. A few things that pushed us towards gRPC... Canonical error codes and semantics. Standards here go such a long way to building reliable systems. The ecosystem. There are a lot of middlewares, validators, transcoders written specifically for the Go gRPC stack. Envoy. This has a lot of things we wanted like rate limiting and auth which are implemented over gRPC. With AWS adopting Envoy for their service mesh offering it’s a safe technology bet now. Performance. This doesn’t matter for our API stack but could be a huge gain in Segments data plane. That said I still wish all this was simpler. Twirp looks like a great choice in that regard.

grpcthrowa1215 8y ago

I work on GRPC. Twirp is serious competitor to GRPC due to being easier to use (as you noticed) and gets most of the benefits just by using Protobuf. It's a problem for us because it's hard to explain the value added. For me, the reason to use GRPC is because there is a very good story about the boring details of networking. The stuff that would make other programmers eyes glaze over but are nonetheless important, has basically been solved by GRPC. What happens when the connection gets dropped but you haven't sent the RPC yet? Does it try to find another server to send it to? Does it time out? What happens if the DNS entries change after you connect? Does it even use all the addresses that DNS returned? If the connection has been idle for for 30 minutes, does it keep it around or shut it down? How does it even know if the connection is good after being idle so long? Home routers have a bad habit of breaking connections due to their NAT. For most of these problems, TCP and UDP only gives you the tools to solve them, but don't do so out of the box. Coming back to Twirp, I don't recall seeing these things addressed in their code, (except what Go's net and http library already provide). If you don't care about those networking details (and it's completely legitimate if you don't, some people don't need to), then I think Twirp's API is much more pleasant to use, and still gets you 80% of the benefit of GRPC.

Game_Ender 8y ago
Is the GRPC API less pleasant because you have to handle those details? Or could it be evolved to be more user friendly?
justicezyx 8y ago
Grpc is the enterprise ready and high-performance rpc infrastructure, I cannot believe Google still cannot figure out the right pitch. There isn't anything in the world that can match grpcs features and still perform at the same level, plus Google's decades of large scale use. Guys, I am so disappointed at how Google push it's internal technology. People won't come to you without pitching, be smart...
- hsaliak 8y ago
  PM for gRPC here. Feedback received! :) What would you like to see us do more of?