RpcNode taking shape, API Viewer for server classes

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

RpcNode taking shape, API Viewer for server classes

panyasan
Hi everybody,

happy to report that the RpcNode json-rpc server based on node.js is starting to work more or less stable. Of course, it is far from being production-ready, that's why I don't make a release yet.

But what really excites me is that I beginning to see the qooxdoo toolchain cross the client-server divide. I have generated an API-Viewer app that displays both the client and the server files:

http://cboulanger.users.sourceforge.net/qooxdoo-contrib/RpcNode/trunk/api/#rpcnode.demo.service.RpcTest

As you can see, the RpcNode demo is a qooxdoo application that inherits from the RpcConsole (which I have showcased in my previous email). The demo contains a "service" folder, in which the server-side rpc classes are located. In addition, the server, an interface for service classes and an exception class are on the server-side. They are normal qooxdoo classes with all the bells and whistles of the oo-system and the doc-comments for the API-Viewer. For example, here is the qooxdoo rpc test suite that is also used in the RpcPhp contribution:

http://qooxdoo-contrib.svn.sourceforge.net/viewvc/qooxdoo-contrib/trunk/qooxdoo-contrib/RpcNode/trunk/demo/default/source/class/rpcnode/demo/service/RpcTest.js?revision=20633&view=markup

Since nodes.js is a one-threaded, event-driven server, special care has to be taken to make the rpc methods non-blocking. As you can see in the second rpc class:

http://qooxdoo-contrib.svn.sourceforge.net/viewvc/qooxdoo-contrib/trunk/qooxdoo-contrib/RpcNode/trunk/demo/default/source/class/rpcnode/demo/service/NodeTest.js?revision=20633&view=markup

I am using the node-promise library which works with the concepts of Promises/Deferred Results which works perfectly with the async nature of node.js. I have already opened an enhancement request (http://bugzilla.qooxdoo.org/show_bug.cgi?id=3999) to port the library to qooxdoo.

Maybe it would be a good idea if the API viewer could have special icons for server-side files or one could find a special name convention to be able to easily differentiate the classes on the client and the server, although there also might be classes (like those in qx-oo) which are used on both sides of the wire.

So much for today, hope you enjoy this!

C.
Reply | Threaded
Open this post in threaded view
|

Re: RpcNode taking shape, API Viewer for server classes

Fabian Jakobs
Administrator
Hi Christian,

nice work. It is cool to see an end to end qooxdoo application. I've
been working with node.js a lot recently. To handle some of the async
issues I've written a small library called async.js
<http://github.com/fjakobs/async.js>. I think this can be a nice
addition to "node-promise".

Best Fabian

On Sat, Aug 14, 2010 at 11:18 PM, panyasan <[hidden email]> wrote:

>
> Hi everybody,
>
> happy to report that the RpcNode json-rpc server based on node.js is
> starting to work more or less stable. Of course, it is far from being
> production-ready, that's why I don't make a release yet.
>
> But what really excites me is that I beginning to see the qooxdoo toolchain
> cross the client-server divide. I have generated an API-Viewer app that
> displays both the client and the server files:
>
> http://cboulanger.users.sourceforge.net/qooxdoo-contrib/RpcNode/trunk/api/#rpcnode.demo.service.RpcTest
>
> As you can see, the RpcNode demo is a qooxdoo application that inherits from
> the RpcConsole (which I have showcased in my previous email). The demo
> contains a "service" folder, in which the server-side rpc classes are
> located. In addition, the server, an interface for service classes and an
> exception class are on the server-side. They are normal qooxdoo classes with
> all the bells and whistles of the oo-system and the doc-comments for the
> API-Viewer. For example, here is the qooxdoo rpc test suite that is also
> used in the RpcPhp contribution:
>
> http://qooxdoo-contrib.svn.sourceforge.net/viewvc/qooxdoo-contrib/trunk/qooxdoo-contrib/RpcNode/trunk/demo/default/source/class/rpcnode/demo/service/RpcTest.js?revision=20633&view=markup
>
> Since nodes.js is a one-threaded, event-driven server, special care has to
> be taken to make the rpc methods non-blocking. As you can see in the second
> rpc class:
>
> http://qooxdoo-contrib.svn.sourceforge.net/viewvc/qooxdoo-contrib/trunk/qooxdoo-contrib/RpcNode/trunk/demo/default/source/class/rpcnode/demo/service/NodeTest.js?revision=20633&view=markup
>
> I am using the node-promise library which works with the concepts of
> Promises/Deferred Results which works perfectly with the async nature of
> node.js. I have already opened an enhancement request
> (http://bugzilla.qooxdoo.org/show_bug.cgi?id=3999) to port the library to
> qooxdoo.
>
> Maybe it would be a good idea if the API viewer could have special icons for
> server-side files or one could find a special name convention to be able to
> easily differentiate the classes on the client and the server, although
> there also might be classes (like those in qx-oo) which are used on both
> sides of the wire.
>
> So much for today, hope you enjoy this!
>
> C.
>
> --
> View this message in context: http://qooxdoo.678.n2.nabble.com/RpcNode-taking-shape-API-Viewer-for-server-classes-tp5424073p5424073.html
> Sent from the qooxdoo mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: RpcNode taking shape, API Viewer for server classes

panyasan
Yes, I think the building blocks for a lightweight architecture for an end-to-end qooxdoo application that communicates, in "real time" (that is, as fast as the transport allows) in both directions are all there, and simply have to be properly configured and made stable. What still misses, at this point, is encryption. If you skip Apache and fully rely on node.js as a server, you have to do all the encryption yourself. Which might be a crucial point.

Cheers,
C.
Reply | Threaded
Open this post in threaded view
|

Re: RpcNode taking shape, API Viewer for server classes

Fabian Jakobs
Administrator
We are using NGINX as reverse proxy. NGING handles SSL encryption and
serves static files. All other requests are forwarded to node.js.

On Tue, Aug 17, 2010 at 7:22 PM, panyasan <[hidden email]> wrote:

>
> Yes, I think the building blocks for a lightweight architecture for an
> end-to-end qooxdoo application that communicates, in "real time" (that is,
> as fast as the transport allows) in both directions are all there, and
> simply have to be properly configured and made stable. What still misses, at
> this point, is encryption. If you skip Apache and fully rely on node.js as a
> server, you have to do all the encryption yourself. Which might be a crucial
> point.
>
> Cheers,
> C.
> --
> View this message in context: http://qooxdoo.678.n2.nabble.com/RpcNode-taking-shape-API-Viewer-for-server-classes-tp5424073p5433126.html
> Sent from the qooxdoo mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: RpcNode taking shape, API Viewer for server classes

panyasan
Hi Fabian,

Fabian Jakobs wrote
We are using NGINX as reverse proxy. NGING handles SSL encryption and
serves static files. All other requests are forwarded to node.js.
hm, but I am thinking of the opposite scenario - I don't really care so much about the static files (== the qooxdoo application), they can go unencrypted to the client. What needs to be encrypted is the data that gets sent with the message-passing and rpc system... I now understand the value of SOAP - but I don't want the overhead of SOAP, I want to stick with simple node.js/json, but prevent others from intercepting sensitive data...

C.
Reply | Threaded
Open this post in threaded view
|

Re: RpcNode taking shape, API Viewer for server classes

Thomas Herchenroeder


On 08/18/2010 05:24 PM, panyasan wrote:

>
> Hi Fabian,
>
>
> Fabian Jakobs wrote:
>>
>> We are using NGINX as reverse proxy. NGING handles SSL encryption and
>> serves static files. All other requests are forwarded to node.js.
>>
>
> hm, but I am thinking of the opposite scenario - I don't really care so much
> about the static files (== the qooxdoo application), they can go unencrypted
> to the client. What needs to be encrypted is the data that gets sent with
> the message-passing and rpc system... I now understand the value of SOAP -
> but I don't want the overhead of SOAP, I want to stick with simple
> node.js/json, but prevent others from intercepting sensitive data...

But if I understood Fabian correctly, *all* communication goes through
the web server first (I would recommend lighttpd over nginx), and then
certain requests are passed to node.js. This would assure encryption for
the rpc requests up to the web server, which should be good enough.

T.

------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: RpcNode taking shape, API Viewer for server classes

panyasan
thron7-2 wrote
> Fabian Jakobs wrote:
>>
>> We are using NGINX as reverse proxy. NGING handles SSL encryption and
>> serves static files. All other requests are forwarded to node.js
>
> hm, but I am thinking of the opposite scenario - I don't really care so much
> about the static files (== the qooxdoo application), they can go unencrypted
> to the client.

But if I understood Fabian correctly, *all* communication goes through
the web server first (I would recommend lighttpd over nginx), and then
certain requests are passed to node.js. This would assure encryption for
the rpc requests up to the web server, which should be good enough.
You're right. I overlooked the "forwarded" part. Seems like a sensible setup - I'll try that, need to figure out how lighttpd works. And for demo projects which don't need ssl, one can use the node server directly.

C.