21 comments

[ 2.9 ms ] story [ 51.9 ms ] thread
I think I understand the remote procedure call concept, but could someone explain how I'd want to use this if I were building a web app?

Would this replace a lot of my ajax calls or... ?

Yeah! You can use dnode on the browser. You'd then be calling functions in your code, which would get executed on the server side. All transparently. No more explicit ajax calls.

Just write a server.js:

    var express = require('express');
    var app = express.createServer();
    app.use(express.static(__dirname));
    
    app.listen(8080);
    console.log('http://localhost:8080/');
    
    // then just pass the server app handle to .listen()!

    var dnode = require('dnode');
    var server = dnode({
        zing : function (n, cb) { cb(n * 100) }
    });
    server.listen(app);
And whip up an index.html:

    <html>
    <head>
    <script src="/dnode.js" type="text/javascript"></script>
    <script type="text/javascript">
        window.onload = function () {
    
            DNode.connect(function (remote) {
                remote.zing(66, function (n) {
                    document.getElementById('result').innerHTML = n;
                });
            });
    
        };
    </script>
    </head>
    <body>

    n = <span id="result">?</span>

    </body>
    </html>
Then just run the server.js:

    $ node server.js
    
And navigate to http://localhost:8080!
is this similar to now.js?
no, now.js is similar to dnode. an even better analog is that now.js is more like a commercial version of socket.io
If you're interested in dnode you should also check out hook.io https://github.com/hookio/hook.io

It uses dnode to essentially let you build an auto-discovering message bus. I recently started using it and so far its been an amazing way to build up small independent services. With almost zero configuration the services can boot up and start talking to each other. It even works in the browser.

Holy moly. That is super cool. I'm still a little unsure of NodeJS as a platform, but the level of innovation in the ecosystem is incredible, very modular and very composable. Impressive stuff.
It's not clear to me what this offers exactly beyond events, which are easy enough in socket.io. And dnode allows very free-style form of RPC where you can have an event/call pass a function that then can be called from the other side.

What is it that makes hook.io exciting?

hook.io isn't about client server communication. It's about seamless mesh communication with high fault tolerance. The browser is just another end point.
I don't quite understand this from the documentation I'm reading. Doesn't high fault tolerance require automatic failover of some sort that goes beyond broadcasting the messages to all Hooks? For instance, if you want to send an SMS robustly are you supposed to have multiple SMS listeners? And if so, how do you avoid sending multiple messages without some sort of ACK or message queue?
So I have been playing with Hook.io for a while too. It is pretty cool, but it should also be pointed out that it is still in early stage development.

Reading the mailing list you can see that hook.io still has some issues to work through: http://groups.google.com/group/hookio

I really liked using dnode, but I had serious scalability problems with it. I didn't have time to look too closely, but I found quite significant latency between sending/receiving messages to the extent that I just downgraded to using socket.io directly and was quite happy. Sorry to be vague, but it's been 8 months since I experienced the issue.

Definitely, give dnode a go. It's a lovely piece of software, but keep an eye out for performance issues.

Same here, we had to abandon usage of it in favor of a simple json-tcp bridge. We were looking at 100ms+ for communication between two ec2 instances; with straight tcp it was closer to 7ms.
Same here, we had to abandon usage of it in favor of a simple json-tcp bridge. We were looking at 100ms+ for communication between two ec2 instances; with straight tcp it was closer to 7ms.
Not to diminish substack's huge achievements, but we used dnode on a project and finally went back to just using socket.io as it worked way better.

The latest socket.io releases have added a lot of features (node client, rooms, ...) that make libraries like dnode less useful imho.

I came across a really nice socket.io benchmarking tool @ a node.js hack event last night ... https://github.com/mixu/siobench

Quite a nice ecosystem forming just around socket/engine/hooks io's

I just built a browser version of the Redis client using dnode, to test it out. Fun and easy to use, and preferable to AJAX. Probably won't replace socket.io where I use it, but could be the foundation for CMS type apps.
Is this in some way significantly better than using normal REST APIs to communicate? It seems to me like we've been through various RPC's in the past (SOAP, XML-RPC, etc.) and REST has generally proven the simplest and most interoperable solution for APIs. Unless you have a need to really optimize and tweak the performance.