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: [email protected] 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 <[email protected]> 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 <[email protected]> > 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 > > >
