[
https://issues.apache.org/jira/browse/THRIFT-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13921679#comment-13921679
]
Randy Abernethy commented on THRIFT-2355:
-----------------------------------------
Hi Henrique,
Great question. I tried several WS libs for Node before deciding to code the
needed bits directly. Five points motivated me to take this approach:
1. Thrift is the right level of abstraction
Conceptually, twiddling bits and managing stream payloads is what Apache Thrift
is for. The WebSocket implementation needed by Apache Thrift is parallel to
that of TFramedTransport, nothing more than a pair of frame encode/decode
methods (about 100 lines of code). The Thrift code base seemed like the logical
home for this stuff. One of the key things 3rd party libs bring is abstraction,
you can write your domain code and use a lib to implement details that you
don’t need to know about. However, we are building a cross language wire
protocol here, we need to know about the frame encoding details, a library only
obscures things.
2. The hardest thing about using Apache Thrift is managing the dependencies
I think long and hard prior to adding new dependencies to Thrift. I set up and
tear down various Apache Thrift dev environments regularly and I inevitably
forget some dependency needed on the particular OS or by the set of languages
to be used. I can sort these issues out because I have been using Thrift for
years, however new users often loose many hours to Thrift configuration
management. I want nothing so much as to make Thrift easier for new developers
to adopt and use. The code I had to write to use popular WebSocket libraries
with Thrift was as long as doing the encode/decode directly, less conformant
with the Thrift I/O stack model, harder to debug and increased the dependency
burden (substantially in several cases). The fastest 3rd party Node libraries
require C and/or C++ compilation. This adds material complexity to something
that should be simple. If it is a little bit harder for us to write some
targeted code but benefits thousands of users by reducing dependencies and
making their use of Thrift simpler, it is an easy decision in my book. I take a
fairly different approach when developing applications, but Thrift is a
framework and dependency questions must be answered in context.
3. Third party WS Libraries are volatile
We have no control over third party library APIs, licenses or life spans. Which
ones will fade away, which will introduce breaking changes without continuing
to provide access to old versions, which have appropriate licenses for the user
base? These problematic questions go away if the code is just part of Thrift.
4. General purpose libraries are overkill for Apache Thrift needs
WebSocket libraries are thousands of lines of code long and provide many high
level features that a low level TTransport implementation has no use for.
5. Thrift cross pollination
My hope is that other developers will look at the Node WebSocket code and port
it directly to other languages. While Node takes care of the HTTP side (deals
with the “upgrade” requests, etc.) the encoding code could be dropped right
into C++, Java or C# with very little work. A Node WS framework would dilute
this benefit.
Interested to hear other perspectives.
Best,
Randy
> Add SSL and Web Socket Support to Node and JavaScript
> -----------------------------------------------------
>
> Key: THRIFT-2355
> URL: https://issues.apache.org/jira/browse/THRIFT-2355
> Project: Thrift
> Issue Type: Improvement
> Components: JavaScript - Compiler, JavaScript - Library, Node.js -
> Library
> Affects Versions: 0.9.2
> Environment: all
> Reporter: Randy Abernethy
> Assignee: Randy Abernethy
> Priority: Minor
> Fix For: 0.9.2
>
> Attachments: 0001-Add-WebSocket-support-to-JS-and-Node.JS.patch
>
>
> This patch adds support for SSL between Node.js and Browser JavaScript as
> well as initial WebSocket transport support.
> The createStaticHTTPThriftServer() method has been renamed
> createThriftWebServer(). The resulting server supports XHR based HTTP:// and
> HTTPS:// clients as well as upgrades to WS:// and WSS:// for websocket
> clients.
> The JavaScript thrift.js library now includes websocket support through
> TWebSocketTransport. The old XHR transport still goes by the alias Transport
> but can now also be accessed through the name TXHRTransport. Browser clients
> can use XHR over HTTP and HTTPS (as always) and also WebSocket (WS://) and
> secure WebSocket (WSS://).
> The JavaScript grunt build runs jQuery and Normal JavaScript synchronous and
> asynchronous tests over HTTP and HTTPS. There are now three test drivers in
> the thrift/lib/js/test directory:
> - test.html the jQuery build test (thrift -gen js:jquery)
> - test-nojq.html the normal JavaScript build test (thrift -gen js)
> - testws.html the (in progress) web socket test.
> The thrift/lib/js/test/sec directory is new with a key.pem and cert.pem for
> the HTTPS test server.
> The root js README was updated and contains a complete client/server example.
> A new README was added to the test directory providing an orientation there.
> The web socket transport works but is experimental and incomplete. Hope to
> get it wrapped up over the next week. With Web Socket in place it makes sense
> to consider adding a binary protocol on the browser side.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
