Thrift vs. Protocol Buffers

[James Hanley <jh...@dgtlrift.com>]

A number of years back, Diwaker Gupta published a great article
"Thrift vs. Protocol Buffers" which eventually moved to
https://old.floatingsun.net/articles/thrift-vs-protocol-buffers/index.html
and then later another article titled "Thrift: The Missing Guide"
landing on https://diwakergupta.github.io/thrift-missing-guide/ 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

Re: Thrift vs. Protocol Buffers

[Jens Geyer <je...@hotmail.com>]

That whole topic has been discussed on SO already.

TL;DR:

- Thrift has 20+ languages out of the box, and RPC out of the box. It is 
flexible and highly agnostic when it comes to transports or protocols.

- protobuf supports that as well, but is more cumbersome to set up, because 
everything (including grpc and basically every target language) is a plugin, 
an addon, or 3rdparty project which wants a special syntax to get it to work

- gRPC biggest plus: it has built-in support for streaming, which requires 
much more work with Thrift
- gRPC biggest minus: you want to use HTTP/2, because that's the only option 
you have

- Both work and are used by lots of companies and projects.

Bottom line: You don't have to eat meat. You can live vegan and be proud of 
it, as long as you compensate what your project actually needs. Both is 
perfectly fine.



-----Ursprüngliche Nachricht----- 
From: Edward Capriolo
Sent: Tuesday, February 20, 2018 9:58 PM
To: user@thrift.apache.org
Subject: Re: Thrift vs. Protocol Buffers

"Last I looked at protobuf it was just a framework for serialization, and
the rest was left to the reader."

Many are using this now: Protobuf is often pared with https://grpc.io/

On Tue, Feb 20, 2018 at 3:41 PM, James E. King, III <jk...@apache.org>
wrote:

> 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 <jh...@dgtlrift.com>
> wrote:
>
> > A number of years back, Diwaker Gupta published a great article
> > "Thrift vs. Protocol Buffers" which eventually moved to
> > https://old.floatingsun.net/articles/thrift-vs-protocol-
> buffers/index.html
> > and then later another article titled "Thrift: The Missing Guide"
> > landing on https://diwakergupta.github.io/thrift-missing-guide/ 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
> >
> 

Re: Thrift vs. Protocol Buffers

[Edward Capriolo <ed...@gmail.com>]

"Last I looked at protobuf it was just a framework for serialization, and
the rest was left to the reader."

Many are using this now: Protobuf is often pared with https://grpc.io/

On Tue, Feb 20, 2018 at 3:41 PM, James E. King, III <jk...@apache.org>
wrote:

> 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 <jh...@dgtlrift.com>
> wrote:
>
> > A number of years back, Diwaker Gupta published a great article
> > "Thrift vs. Protocol Buffers" which eventually moved to
> > https://old.floatingsun.net/articles/thrift-vs-protocol-
> buffers/index.html
> > and then later another article titled "Thrift: The Missing Guide"
> > landing on https://diwakergupta.github.io/thrift-missing-guide/ 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
> >
>

Re: Thrift vs. Protocol Buffers

["James E. King, III" <jk...@apache.org>]

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 <jh...@dgtlrift.com> wrote:

> A number of years back, Diwaker Gupta published a great article
> "Thrift vs. Protocol Buffers" which eventually moved to
> https://old.floatingsun.net/articles/thrift-vs-protocol-buffers/index.html
> and then later another article titled "Thrift: The Missing Guide"
> landing on https://diwakergupta.github.io/thrift-missing-guide/ 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
>