I think it's more that GRPC (Google's RPC-over-HTTP2 protocol) directly supports Protobuf, and not Flatbuffers. All of Google's Cloud APIs use Protobuf (for example the [Speech API](https://cloud.google.com/speech/reference/rpc/) ).
I have to say, GRPC is pretty great. It's statically typed, supports loads of languages, the interfaces are simple to define (basically Protobuf), and it supports streaming requests! Most RPC systems omit that, or only have message streams (e.g. MQTT). Good RPC systems need both.
The only downside I find is that it is rather complicated (in design; not use).
Been using flatbuffers in production for a high speed market feed for a month now. Love it. Decode/encode time is absurdly fast (~1-2 microseconds for a small to medium schema). If you're pushing 50k+ events/second it can be a great choice. Takes up almost no space on the wire too.
"With that said, my intuition is that SBE will probably edge Cap’n Proto and FlatBuffers on performance in the average case, due to its decision to forgo support for random access. Between Cap’n Proto and FlatBuffers, it’s harder to say. FlatBuffers’ vtable approach seems like it would make access more expensive, though its simpler pointer format may be cheaper to follow. FlatBuffers also appears to do a lot of bookkeeping at encoding time which could get costly (such as de-duping vtables), but I don’t know how costly.
For most people, the performance difference is probably small enough that qualitative (feature) differences in the libraries matter more."
Because it’s easy to pick on myself. :) I, Kenton Varda, was
the primary author of Protocol Buffers version 2, which is the
version that Google released open source. Cap’n Proto is the
result of years of experience working on Protobufs, listening
to user feedback, and thinking about how things could be done
better.
To be completely fair, Protobus v3 is also the result of years of experience working on Protobufs, listening to user feedback, and thinking about how things could be done better :)
I have to say, GRPC is pretty great. It's statically typed, supports loads of languages, the interfaces are simple to define (basically Protobuf), and it supports streaming requests! Most RPC systems omit that, or only have message streams (e.g. MQTT). Good RPC systems need both.
The only downside I find is that it is rather complicated (in design; not use).