thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jens Geyer" <jensge...@hotmail.com>
Subject Re: Thrift vs JSON/HTTP for new service
Date Wed, 28 Jan 2015 21:48:31 GMT
Hi,

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

We have a service that can be talked to via Thrift or SOAP. Exact same 
interface. You could even switch between them between calls. We solved it by 
developing a small DSL to create the code for those different layers that 
needed on the server end, including the Thrift IDL file.

What helped us a lot during that process, we applied some (minor) 
constraints to make our life easier. For example, we don't use Thrifts maps 
for that project, because they are quite hard to model with SOAP. It's not 
impossible to add that though, if we need it in the future.

Regarding performance: Sure, due to the additional layer we may copy some 
stuff around more than necessary. Even with all those extras, the whole 
service API stack takes next to no time in comparison, since the biz logic 
and the DB access typically eats most of the call time. So we can live with 
it.

If you look in the mailing list archives, there are some older posts from me 
regarding that topic.

Have fun,
JensG


-----Ursprüngliche Nachricht----- 
From: Gallagher Polyn
Sent: Wednesday, January 28, 2015 2:05 PM
To: user@thrift.apache.org
Subject: Re: Thrift vs JSON/HTTP for new service

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
SOA


...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!

G 


Mime
View raw message