3 ms·

Google also has flatbuffers. I wonder if flatbuffers is being used by enough developers to justify significant development? https://github.com/google/flatbuffe

Google also has flatbuffers. I wonder if flatbuffers is being used by enough developers to justify significant development? https://github.com/google/flatbuffers https://github.com/google/flatbuffers

IshKebab 10y ago
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/ 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).
- forrestthewoods 10y ago
  As an FYI, GRPC support was added to flatbuffers a month ago. https://github.com/google/flatbuffers/tree/master/grpc https://github.com/google/flatbuffers/tree/master/grpc
alfalfasprout 10y ago
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.
- amluto 10y ago
  Try Cap'n Proto instead. Better designed and faster.
  - 0xmohit 10y ago
    Kenton Varda (the author of Cap'n Proto), was the primary author of Protocol Buffers version 2. Quoting from https://capnproto.org/index.html https://capnproto.org/index.html 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.
    - euyyn 10y ago
      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 :)
  - RyanZAG 10y ago
    Faster? To quote the author of Cap'n Proto: > https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-sbe.html https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-... "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."

Google also has flatbuffers. I wonder if flatbuffers is being used by enough developers to justify significant development? https://github.com/google/flatbuffers https://github.com/google/flatbuffers

IshKebab 10y ago

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/ 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).

forrestthewoods 10y ago
As an FYI, GRPC support was added to flatbuffers a month ago. https://github.com/google/flatbuffers/tree/master/grpc https://github.com/google/flatbuffers/tree/master/grpc

alfalfasprout 10y ago

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.

amluto 10y ago
Try Cap'n Proto instead. Better designed and faster.
- 0xmohit 10y ago
  Kenton Varda (the author of Cap'n Proto), was the primary author of Protocol Buffers version 2. Quoting from https://capnproto.org/index.html https://capnproto.org/index.html 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.
  - euyyn 10y ago
    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 :)
- RyanZAG 10y ago
  Faster? To quote the author of Cap'n Proto: > https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-sbe.html https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-... "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."