Hi Gallagher, I think one of the key factors in thinking about Thrift and HTTP/JSON is whether you are going to go with a Resource Oriented Architecture (ROA) or a Service Oriented Architecture (SOA). ROA lends itself to REST and using HTTP verbs like GET/PUT/POST/DELETE/PATCH, media types, hypermedia and the like. SOA lends itself to RPC (SOAP, Thrift, Protobufs, etc.) where interfaces are composed of functions (not operations on resources).
In my personal experience, I have found the architecture of the web (distributed caches, firewalls,etc.) easier to leverage with REST and ROA. Interoperability is extreme, reach is fantastic, performance is ok to great, depending on your balance of cachable verses non cachable calls. The web is ROA and the Internet is designed to support this at every level. Apache Thrift is much faster in cases where dynamic operations are involved, that is to say, where the client actually needs to talk to the server, not an intermediary. Thrift fits well as a general purpose solution on the backend and in some cases even the front end. Underrated, I think, is also the cross language serialization features of Apache Thrift. For example we use Thrift to serialize messages (Thrift structs), in particular for transport over RabbitMQ/Apollo/ZeroMQ etc. If you are doing SOA, Thrift is pretty great. Also keep in mind that in regards to many workflows, folks have been trying to get out of the HTTP channel for quite a while. WebSocket was created to allow us to eliminate the overhead of HTTP in the browser. Thrift is happy to communicate over HTTP, WebSocket or a string an two tin cans. The architecture is pretty elegant and extensible. For extreme IPC (Inter Process Communications) speed I have found that just grabbing bits out of RAM and sending them is hard to beat. No serialization overhead, no mem copies, etc. On the other hand this is a very brittle approach and needs the right languages and justification. The fact that you can evolve Thrift (and REST) interfaces without breaking existing code it a huge feature to give up, easily justifying the serialization overhead of Thrift in most settings. So in my view (and it is not the right view, just a view): 1. ROA and REST: great for internet facing broadly distributed, read mostly interfaces 2. Hand coded IPC: great for extreme scenarios (brittle, not needed by most and hard to justify) 3. Thrift: great for everything else (which I find is a lot), in particular SOA My 2 cents, Randy On Tue, Jan 27, 2015 at 10:27 AM, Gallagher Polyn <[email protected]> wrote: > I am unsure whether to specify a new service in terms of Thrift or JSON/HTTP. > > I have read an elaboration by an original Thrift author, Mark Slee, of > relevant decision points on this matter,* including expected gain from the > advantages of strong typing, performance, serialization efficiency. > versioning support and server implementation, but I do not know how assess > those relative benefits for my new service, now. > > Allowing an even chance that the benefits of a Thrift service implementation > would later be judged superior to JSON/HTTP, is it still preferable to > specify the service (test specs) in terms of JSON/HTTP and migrate later? Or, > alternatively, might it be better to specify Thrift services and 'layer on’ a > JSON/HTTP interface? > > * > http://www.quora.com/What-are-the-use-cases-for-Thrift-i-e-what-reasons-are-there-to-consider-using-Thrift-when-one-could-rely-on-JSON-and-standard-HTTP-requests > > <http://www.quora.com/What-are-the-use-cases-for-Thrift-i-e-what-reasons-are-there-to-consider-using-Thrift-when-one-could-rely-on-JSON-and-standard-HTTP-requests>
