4 ms·

Personally I don't think that gRPC is a good step forward. However, if the community at large moves away from REST + JSON to gRPC I'll follow. Why? - I don't

by brad0 8y ago

Personally I don't think that gRPC is a good step forward. However, if the community at large moves away from REST + JSON to gRPC I'll follow. Why? - I don't want to be like the guy who refuses to use anything but XML + SOAP - I want to be valuable on the job market. Putting gRPC may get you in the door - Avoid bikeshedding Anyone who's been in the industry a few years knows that "the way" to do things changes often. Going with the flow and completing the actual job is what matters.

asdkhadsj 8y ago
Mind commenting on what you think would be better? Personally I'm in love with the idea of protobufs, but I'm not terribly sold on the implementation. The language is great, but the mapping to code languages is not great. Eg, to make great idiomatic Go code, I need to litter my Protobuf with extensions (via Gogoprotobuf) and the readability of the Protobuf sort of goes down the tubes. So I think the idea behind Protobuf is great, and the syntax itself looks great, but a small tweak to how it handles code generation would be very welcome. Likewise gRPC feels quite verbose. I use it, but conceptually I massively prefer simplistic implementations like Twirp[1]. However, again Protobuf handles this really nicely in that I can use the same Protobuf file to describe a Twirp or gRPC Service - it's great. [1]: https://github.com/twitchtv/twirp https://github.com/twitchtv/twirp So what do you think would be a better step forward?
ljm 8y ago
I found gRPC to be exciting when I was writing something in Go. The tooling around that is pretty decent and it sets a certain expectation about how it works. Then I had to write a client in a different language, and the generated code was utterly intuitive. gRPC itself adds extensions to Protobuf to handle code-gen nuances but of course they're deployed in Go-land, not relevant-language-land. That's a small niggle that's easily solved one way or another. What was frustrating was that the `protobuf` CLI could handle language extensions, but you couldn't make use of that without a hell of a lot of faff. If you want to add a gRPC client to your Rails app you can't use the protobuf CLI, that you might already have.... you have to add a gem that includes a different version of the protobuf CLI that is guaranteed to be not compatible. Even the command and its args aren't compatible. When I found myself working against that I just gave up. It's a solution that sounds elegant, but you're going to get a feature out of the door much quicker if you steer away from that layer altogether. There's nothing wrong with an ad-hoc HTTP API if you're confident about the interface. Technical purity isn't technical excellence and nor is it user value. Just like K8S, you're not gonna need RPC on the web unless you can justify the scale and have the firepower to handle it.

by brad0 8y ago

asdkhadsj 8y ago

Mind commenting on what you think would be better? Personally I'm in love with the idea of protobufs, but I'm not terribly sold on the implementation. The language is great, but the mapping to code languages is not great. Eg, to make great idiomatic Go code, I need to litter my Protobuf with extensions (via Gogoprotobuf) and the readability of the Protobuf sort of goes down the tubes. So I think the idea behind Protobuf is great, and the syntax itself looks great, but a small tweak to how it handles code generation would be very welcome. Likewise gRPC feels quite verbose. I use it, but conceptually I massively prefer simplistic implementations like Twirp[1]. However, again Protobuf handles this really nicely in that I can use the same Protobuf file to describe a Twirp or gRPC Service - it's great. [1]: https://github.com/twitchtv/twirp https://github.com/twitchtv/twirp So what do you think would be a better step forward?

ljm 8y ago

I found gRPC to be exciting when I was writing something in Go. The tooling around that is pretty decent and it sets a certain expectation about how it works. Then I had to write a client in a different language, and the generated code was utterly intuitive. gRPC itself adds extensions to Protobuf to handle code-gen nuances but of course they're deployed in Go-land, not relevant-language-land. That's a small niggle that's easily solved one way or another. What was frustrating was that the `protobuf` CLI could handle language extensions, but you couldn't make use of that without a hell of a lot of faff. If you want to add a gRPC client to your Rails app you can't use the protobuf CLI, that you might already have.... you have to add a gem that includes a different version of the protobuf CLI that is guaranteed to be not compatible. Even the command and its args aren't compatible. When I found myself working against that I just gave up. It's a solution that sounds elegant, but you're going to get a feature out of the door much quicker if you steer away from that layer altogether. There's nothing wrong with an ad-hoc HTTP API if you're confident about the interface. Technical purity isn't technical excellence and nor is it user value. Just like K8S, you're not gonna need RPC on the web unless you can justify the scale and have the firepower to handle it.