thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Abernethy>
Subject Re: Thrift vs JSON/HTTP for new service
Date Thu, 29 Jan 2015 02:08:37 GMT
>> [3] 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.
> Randy, can you elaborate on why a web service design would call for an
> intermediary, unless it were post hoc?

Just referring to the tiers of caching that web tech provides. For example if
a REST client makes a GET request for a resource which has not timed out,
a cache (browser/proxy/reverseproxy/etc.) could return it. Hard to beat a
cache hit for speed.

Thrift would always call through to the server (without custom cache
If you always call through to the server the browser/proxy/reverse proxy caches
don't help and Thrift would likely be faster than REST.

> 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....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.
>> In this bit, Randy, are you expressing a connection between 'extreme IPC'
> and 'the fact that you can evolve Thrift interfaces'? If so, I don't
> understand, but would like to.

Just saying that if you grab bits out of memory and send them and then
later change the structure of the bits, the guy receiving them needs to be
rewritten. With Thrift you can add and remove fields, and with
care, change cardinalities and types without breaking existing clients/servers.
Also Thrift's ability to handle maps (as Jens mentions), lists and sets is a
big win over some other approaches.


View raw message