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.

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

So what do you think would be a better step forward?