thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Abernethy ...@apache.org>
Subject Re: Thrift vs JSON/HTTP for new service
Date Tue, 27 Jan 2015 19:28:56 GMT
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
<gallagher.polyn@gmail.com> 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>

Mime
View raw message