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: [email protected]
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
