thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gallagher Polyn <>
Subject Re: Thrift vs JSON/HTTP for new service
Date Wed, 28 Jan 2015 13:05:40 GMT
Thanks Phillip and Randy for your responses. I've added a couple of brief
comments/questions to digested versions, farther below.

I had written (condensed here):

'I am unsure whether to specify a new service in terms of Thrift or
JSON/HTTP [...] 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?'

..and Phillip responded:

"Personally, I usually develop the Thrift services first and 'layer on' a
JSON/HTTP interface to support integration with third party systems built
by other developers who don't fancy Thrift.

So, technically; I deliver two APIs. And depending on the expertise of the
integrator, they choose which one they want to speak to*.*"

Phillip, that sounds time-consuming, unless the HTTP/JSON layering is kind
of boilerplate. Can you refer me to any references that describe something
like your steps?

Meanwhile, Randy wrote (edited):

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

...which he had elaborated (thanks!)...

[1] 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).
> [1] I have found the architecture of the web...

easier to leverage with REST and
> ROA....The web is ROA and the Internet is designed to support this at
> every level.

Great, helpful!

> [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?

> [3] 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.

OK, this guidance sounds relevant when a service is known to be backend.

> [1,3] 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.

OK, this guidance sounds relevant when a front-end service use case might
call for WebSockets

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.

Thanks again!


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message