[
https://issues.apache.org/jira/browse/THRIFT-2995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14317547#comment-14317547
]
Igor Tkach edited comment on THRIFT-2995 at 2/12/15 4:07 AM:
-------------------------------------------------------------
Randy, Andrew, thank you for your responses.
I was able to get nodejs thrift to work in the browser with
webpack (from master branch at 96f4f07beb - I
noticed some patches for browserify were recently added and didn't
make it into release yet) with the help of webpack's
{{NormalModuleReplacementPlugin}}.
First I copied thrift module to project's {{web_modules/}} directory (one of
the places where webpack looks for modules):
{code}
cd myproject
cp -r ~/thrift/lib/nodejs/lib/thrift web_modules/
{code}
Then I created file {{mythrift.js}} in {{web_modules/}} directory with
this content:
{code:javascript}
exports.Thrift = require('./thrift/thrift');
var httpConnection = require('./thrift/http_connection');
exports.HttpConnection = httpConnection.HttpConnection;
exports.createHttpConnection = httpConnection.createHttpConnection;
exports.createHttpClient = httpConnection.createHttpClient;
exports.Int64 = require('node-int64');
exports.Q = require('q');
exports.TBufferedTransport = require('./thrift/transport').TBufferedTransport;
exports.TBinaryProtocol = require('./thrift/protocol').TBinaryProtocol;
{code}
and finally I added {{NormalModuleReplacementPlugin}} to
{{webpack.config.js}}:
{code:javascript}
//...
plugins: [
new webpack.NormalModuleReplacementPlugin(/^thrift$/, 'mythrift')
],
//...
{code}
This appears to be very usable and works nicely, although I didn't have
a chance to try it beyond a toy application, so I can't tell how bad
are the problems you mention with error handling from a practical app
development point of view.
So it seems that the only immediate problem which necessitates a hack
like {{NormalModuleReplacementPlugin}} is the fact that generated
.js files use {{require('thrift')}}. If, instead, generated files used
exact modules they need directly, like
{{require('thrift/thrift')}}, {{require('q')}} and
{{require('node-int64')}}, then thrift/index.js could probably be
ignored altogether by those who don't want to everything.
Actually, it appears that having mutliple npm packages rather than single
all-in-one package would better reflect the modular nature of
components that comprise thrift and would make it easier to use -
something like _thrift-core_ (or maybe _thrift-types_?),
_thrift-transport-buffered_, _thrift-transport-framed_,
_thrift-protocol-binary_ and so on.
I also noticed that generated types js file requires q but it is
actually unused. I have a very simple .thrift file though. I was
wondering if there's ever a case where promises would be need in types
file?
Speaking of promises - I think it's a great improvement over
callbacks, honestly I'm not sure why would anyone would want to remove
them. One thing that would be nice is to be able to use any
spec-compliant implementation, such as when.js or native ES6 if
available, although I don't know what's a good way to implement
this. Another area where promises may potentially be useful is error handling,
as
an alternative to events.
I'm just getting my feet wet with thrift, so it'll probably be some
time before I have any patches, but when I do will certainly share.
was (Author: itkach):
Randy, Andrew, thank you for your responses.
I was able to get nodejs thrift to work in the browser with
webpack (from master branch at 96f4f07beb - I
noticed some patches for browserify were recently added and didn't
make it into release yet) with the help of webpack's
{{NormalModuleReplacementPlugin}}.
First I copied thrift module to project's {{web_modules/}} directory (one of
the places where webpack looks for modules):
cd myproject
cp -r ~/thrift/lib/nodejs/lib/thrift web_modules/
Then I created file {{mythrift.js}} in {{web_modules/}} directory with
this content:
{code:javascript}
exports.Thrift = require('./thrift/thrift');
var httpConnection = require('./thrift/http_connection');
exports.HttpConnection = httpConnection.HttpConnection;
exports.createHttpConnection = httpConnection.createHttpConnection;
exports.createHttpClient = httpConnection.createHttpClient;
exports.Int64 = require('node-int64');
exports.Q = require('q');
exports.TBufferedTransport = require('./thrift/transport').TBufferedTransport;
exports.TBinaryProtocol = require('./thrift/protocol').TBinaryProtocol;
{code}
and finally I added {{NormalModuleReplacementPlugin}} to
{{webpack.config.js}}:
{code:javascript}
//...
plugins: [
new webpack.NormalModuleReplacementPlugin(/^thrift$/, 'mythrift')
],
//...
{code}
This appears to be very usable and works nicely, although I didn't have
a chance to try it beyond a toy application, so I can't tell how bad
are the problems you mention with error handling from a practical app
development point of view.
So it seems that the only immediate problem which necessitates a hack
like {{NormalModuleReplacementPlugin}} is the fact that generated
.js files use {{require('thrift')}}. If, instead, generated files used
exact modules they need directly, like
{{require('thrift/thrift')}}, {{require('q')}} and
{{require('node-int64')}}, then thrift/index.js could probably be
ignored altogether by those who don't want to everything.
Actually, it appears that having mutliple npm packages rather than single
all-in-one package would better reflect the modular nature of
components that comprise thrift and would make it easier to use -
something like thift-core (or thift-types?),
thrift-transport-buffered, thrift-transport-framed,
thrift-protocol-binary and so on.
I also noticed that generated types js file requires q but it is
actually unused. I have a very simple .thrift file though. I was
wondering if there's ever a case where promises would be need in types
file?
Speaking of promises - I think it's a great improvement over
callbacks, honestly I'm not sure why would anyone would want to remove
them. One thing that would be nice is to be able to use any
spec-compliant implementation, such as when.js or native ES6 if
available, although I don't know what's a good way to implement
this. Another area where promises may potentially be useful is error handling,
as
an alternative to events.
I'm just getting my feet wet with thrift, so it'll probably be some
time before I have any patches, but when I do will certainly share.
> nodejs: index.js requires too much
> ----------------------------------
>
> Key: THRIFT-2995
> URL: https://issues.apache.org/jira/browse/THRIFT-2995
> Project: Thrift
> Issue Type: Bug
> Components: Node.js - Library
> Affects Versions: 0.9.2
> Environment: webpack
> Reporter: Igor Tkach
>
> THRIFT-2387 requested centralizing external exports in index.js. Required
> modules that are now in index.js create unnecessary and problematic
> dependencies which make it impossible to use thrift module in browser via
> tools like webpack. Client code may avoid using {{require('thrift')}} import
> like so:
> {code:javascript}
> var options = {
> transport: require('thrift/transport').TBufferedTransport,
> protocol: require('thrift/protocol').TBinaryProtocol,
> path: "/",
> headers: {"Connection": "close"},
> https: false,
> responseType: 'arraybuffer'
> };
> var httpConnection = require('thrift/http_connection');
> var con = httpConnection.createHttpConnection("localhost", 8888, options);
> var client = httpConnection.createHttpClient(MyService, con);
> {code}
> but unfortunately generated {{MyService}} nodejs module contains
> {{require('thrift')}} which tries to bring in connection, ws_connection,
> server and web_server all of which of course are unwanted in the browser and
> depend on node modules that can't work in the browser.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
