4 ms·

I think one big win could be to just hide the underlying APIs with better tooling. For example, with GRPC your client bindings are automatically compiled and y

I think one big win could be to just hide the underlying APIs with better tooling. For example, with GRPC your client bindings are automatically compiled and you just use them. Is it using protocol buffers? Do you care? To a certain extent we do care. A lot of these things "just work" out of the box but there are some practical real world implications here. At Datastreamer we push about about 100GB of JSON to our customers per day. This is all news and blog content. Sometimes our customers complain that using JSON is a waste. Realistically though it costs them about $150 extra per month to parse the JSON vs using protocol buffers. We made this decision because implementing JSON is a LOT easier than implementing protocol buffers. Most of our customers end up putting a junior or intermediate engineer on the implementation and they're already familiar with JSON. However, if the tooling hides the encoding and even the wire protocol this means we can upgrade faster. We're still not at a point yet where the tooling is free. You tend to get stuck around something like GRPC or GraphQL anyway. Hopefully this is resolve in the future and we can get all this infrastructure optimization for free.

denormalfloat 8y ago
> Is it using protocol buffers? Do you care? I don't, but other people do. For anything low latency, the cost of encoding/decoding starts to become extremely difficult to avoid. But that said, I'm pretty sure GRPC can use JSON internally, so it's up to you which encoding to use.
- philwelch 8y ago
  > For anything low latency, the cost of encoding/decoding starts to become extremely difficult to avoid. Whether this is an argument against JSON and in favor of Protobuf or vice-versa depends on which language you're operating in. Most benchmarks I've seen show that Protobuf is faster to encode and decode for Java and Golang while JSON is faster for Python and Javascript. IMO, if you're worried about low latency, you're also likely using a compiled language where Protobuf will be faster anyway.
- AceJohnny2 8y ago
  > For anything low latency, the cost of encoding/decoding starts to become extremely difficult to avoid. Consider this: At the scale Google operates, fractions of a % of improvement are worth doing for saving the company (tens/hundreds/more) thousands of dollars in CPU/energy/anything, and they have the people to throw at the problem. Does an alternative solution really improve any/all of throughput/latency/reliability?
wvenable 8y ago
> I think one big win could be to just hide the underlying APIs with better tooling. This is what happened with SOAP because SOAP is too complicated to use without tooling. When it works, it's great. When it doesn't work, it's a nightmare. The reason we use things like JSON and REST is because of the transparency and simplicity that it provides. There isn't much mystery when you need to debug. That's the trade off against things like bandwidth and performance. I'm not really disagreeing with your point; it's easily to look at all this and wonder why we don't do it better and faster.
- pjmlp 8y ago
  And then one quickly misses the tooling when building requests by hand.
jimbokun 8y ago
"Is it using protocol buffers? Do you care?" This is exactly why "RPC" solutions have always failed in the past. The abstraction is too leaky. They quickly become almost impossible to debug, because the underlying implementation is needlessly opaque and complex (cough SOAP). For the foreseeable future, there will always be more and better tools for analyzing and debugging HTTP and making ad hoc HTTP requests.

denormalfloat 8y ago

> Is it using protocol buffers? Do you care? I don't, but other people do. For anything low latency, the cost of encoding/decoding starts to become extremely difficult to avoid. But that said, I'm pretty sure GRPC can use JSON internally, so it's up to you which encoding to use.

philwelch 8y ago
> For anything low latency, the cost of encoding/decoding starts to become extremely difficult to avoid. Whether this is an argument against JSON and in favor of Protobuf or vice-versa depends on which language you're operating in. Most benchmarks I've seen show that Protobuf is faster to encode and decode for Java and Golang while JSON is faster for Python and Javascript. IMO, if you're worried about low latency, you're also likely using a compiled language where Protobuf will be faster anyway.
AceJohnny2 8y ago
> For anything low latency, the cost of encoding/decoding starts to become extremely difficult to avoid. Consider this: At the scale Google operates, fractions of a % of improvement are worth doing for saving the company (tens/hundreds/more) thousands of dollars in CPU/energy/anything, and they have the people to throw at the problem. Does an alternative solution really improve any/all of throughput/latency/reliability?

wvenable 8y ago

> I think one big win could be to just hide the underlying APIs with better tooling. This is what happened with SOAP because SOAP is too complicated to use without tooling. When it works, it's great. When it doesn't work, it's a nightmare. The reason we use things like JSON and REST is because of the transparency and simplicity that it provides. There isn't much mystery when you need to debug. That's the trade off against things like bandwidth and performance. I'm not really disagreeing with your point; it's easily to look at all this and wonder why we don't do it better and faster.

pjmlp 8y ago
And then one quickly misses the tooling when building requests by hand.

jimbokun 8y ago

"Is it using protocol buffers? Do you care?" This is exactly why "RPC" solutions have always failed in the past. The abstraction is too leaky. They quickly become almost impossible to debug, because the underlying implementation is needlessly opaque and complex (cough SOAP). For the foreseeable future, there will always be more and better tools for analyzing and debugging HTTP and making ad hoc HTTP requests.