3 ms·

> and serialization is often only a few percent of that A few percent is a huge performance win. For example shaving 5% off the latency of twitter / facebook's

> and serialization is often only a few percent of that A few percent is a huge performance win. For example shaving 5% off the latency of twitter / facebook's apis is huge. Thing about the compute, energy and bottom line impacts. I do agree for many protobuf is overkill, there's way lower hanging fruit that will give a greater latency reduction.

abernard1 8y ago
Here would be my honest response to that: are you building a Facebook/Twitter scale app? I've watched quite a few companies waste a lot of time with static IDL systems for performance reasons (going back to CORBA in the 90s) and have had the exact opposite effect. Facebook has Thrift internally but ultimately ended up building GraphQL because orchestration and parallelism was the limiting factor (they also need a giant amount of coordination glue code to map from Thrift to JSON anyways). Netflix had similar problems which resulted in them building Falcor. gRPC-web, as well, needs this serialization hop step, so depending on your use case, it may actually be slower. The last two companies I've worked at were in the 50-300 services range with 50K+ business customers and in the 10M+ B2C consumer usage range, and in both cases the IDL translation case (gRPC in one and Thrift in the other) was slower than JSON for many of their applications. Not all cases mind you, but it was definitely hit or miss. In regards to utilization as well, will the reduced overhead of server CPU utilization for protobuf return a higher ROI than the added engineering time of the solution vs something like Swagger codegen? Will the engineers' extra energy expenditure for their work ever make up for the (potentially) reduced servers? These are serious questions and I think a lot of companies waste a lot of effort and resources by not answering those questions honestly.
- philwelch 8y ago
  The performance advantages of a binary wire format are frankly just the cherry on top. The primary benefits of something like gRPC lie in having a programmatically consumable API spec that can turn your service calls into strongly typed RPC’s, and that benefit is a net gain in engineering productivity rather than a net loss. You can get much of the same benefit with swagger codegen, though. It’s just that by the time you’re doing that, gRPC wouldn’t be that much more work anyway. Incidentally, the dividing line between where programming languages are faster at handling protobuf than JSON, namely the dividing line between interpreted and compiled languages, is also the same one where you start to care about performance in the first place. And in Java or Golang, I’m not sure that gRPC is any more difficult.
  - dnautics 8y ago
    Is swagger codegen a ton of work? I wrote a swagger codegen library for elixir (by hand) and that took a few weeks, but setting it up is basically three lines of code and a single mix command. Anyone else could use my library and be up and running in a hot second.

abernard1 8y ago

Here would be my honest response to that: are you building a Facebook/Twitter scale app? I've watched quite a few companies waste a lot of time with static IDL systems for performance reasons (going back to CORBA in the 90s) and have had the exact opposite effect. Facebook has Thrift internally but ultimately ended up building GraphQL because orchestration and parallelism was the limiting factor (they also need a giant amount of coordination glue code to map from Thrift to JSON anyways). Netflix had similar problems which resulted in them building Falcor. gRPC-web, as well, needs this serialization hop step, so depending on your use case, it may actually be slower. The last two companies I've worked at were in the 50-300 services range with 50K+ business customers and in the 10M+ B2C consumer usage range, and in both cases the IDL translation case (gRPC in one and Thrift in the other) was slower than JSON for many of their applications. Not all cases mind you, but it was definitely hit or miss. In regards to utilization as well, will the reduced overhead of server CPU utilization for protobuf return a higher ROI than the added engineering time of the solution vs something like Swagger codegen? Will the engineers' extra energy expenditure for their work ever make up for the (potentially) reduced servers? These are serious questions and I think a lot of companies waste a lot of effort and resources by not answering those questions honestly.

philwelch 8y ago
The performance advantages of a binary wire format are frankly just the cherry on top. The primary benefits of something like gRPC lie in having a programmatically consumable API spec that can turn your service calls into strongly typed RPC’s, and that benefit is a net gain in engineering productivity rather than a net loss. You can get much of the same benefit with swagger codegen, though. It’s just that by the time you’re doing that, gRPC wouldn’t be that much more work anyway. Incidentally, the dividing line between where programming languages are faster at handling protobuf than JSON, namely the dividing line between interpreted and compiled languages, is also the same one where you start to care about performance in the first place. And in Java or Golang, I’m not sure that gRPC is any more difficult.
- dnautics 8y ago
  Is swagger codegen a ton of work? I wrote a swagger codegen library for elixir (by hand) and that took a few weeks, but setting it up is basically three lines of code and a single mix command. Anyone else could use my library and be up and running in a hot second.