thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James E. King, III" <>
Subject Re: Thrift vs. Protocol Buffers
Date Tue, 20 Feb 2018 20:41:19 GMT
That's an interesting angle; I haven't looked into it though.
It might be possible to use a protobuf protocol layer but you would have to
provide that yourself.

One of the strengths of thrift is that it generates the client and server
code for you, and provides libraries for over 20 languages
that are decently tested against each-other for interoperability.
Last I looked at protobuf it was just a framework for serialization, and
the rest was left to the reader.
Multi-threaded servers are fairly complex machines...

It's all just bytes on a wire; so it should be possible to achieve some
level of interoperability; you will probably run into issues
with things like optional/required/default parameters (if one supports it
and one does not), and thrift service methods
won't translate into protobuf structures.

- Jim

On Fri, Feb 16, 2018 at 1:04 PM, James Hanley <> wrote:

> A number of years back, Diwaker Gupta published a great article
> "Thrift vs. Protocol Buffers" which eventually moved to
> and then later another article titled "Thrift: The Missing Guide"
> landing on also
> highlighting some of the differences between the two and the
> reasoning.
> Is there any additional updated documentation as these are around 3 to
> 5 years old comparing some of the capabilities of each?
> Also, it wasn't completely obvious but if I want to implement an
> application that interoperates with a system implemented with Protocol
> Buffers, the application must also use PB and cannot use Apache Thrift
> with a Thrift Protocol that will interoperate with Protocol Buffer
> encoding/decoding? My guess is either that is not possible due to
> design decisions regarding signed values in Thrift and/or enum
> definitions - or possible but not implemented.
> Part of the attraction to AT is that the protocol can be abstracted
> regardless of implementation or language choice, but we need to also
> interoperate with systems implemented using Protocol Buffers.
> Thanks in advance for insight,
> -Jim

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message