Introducing NowJS or "How to make a chat server in 12 lines of code"

by sthatipamala • 15 years ago

241 32 15 years ago

sinaiman• 15 years ago

But will it blend?

oomkiller• 15 years ago

Wow, I've already thought of a bunch of cool ways I could use this. Although, it does remind me of runat="server" for some reason. :)

sthatipamala5• 15 years ago

Yes, we've taken a little inspiration from Jaxer. But NowJS is much friendlier since you have the power of the Node.js support.

Lennie• 15 years ago

I think ASP was first to implement this.

substack6• 15 years ago

Rival node.js RPC project (dnode) author chiming in here.

This is pretty neat and I like the emphasis on getting stuff going in as few lines as possible but I'm not convinced that return values and implicit result callbacks are the way to go for asynchronous requests, which is how I understand this project to work. Often when you want to make a remote call you'll be doing some I/O on the server side, which in node is asynchronous so you can't return right away. Passing along a callback from the client side works much better when the I/O actions have some values to call the client back with.

ericz3• 15 years ago

Hey substack,

The implicit callback is definitely my least favorite part in building NowJS. You can still pass in an additional callback to do any asynchronous I/O. We're trying to find ways to make this experience better for the next version

substack6• 15 years ago

The solution I settled on for dnode is that a deep traversal finds all the functions in your argument list, pulls them out, and wraps them. This part of the protocol is a reusable module if you want to go with it:

https://github.com/substack/dnode-protocol

It's written for continuation-passing style but it shouldn't be too hard to retrofit it for other call styles if you want to preserve explicit returns for instance.

chrisdew• 15 years ago

I've just written JSON-RPC over SocketIO (for another project). I was going to open-source it. Is NowJS a superset of this? If so, I don't want to create noise by releasing a less-functional alternative.

catshirt• 15 years ago

how does this compare to dnode?

substack6• 15 years ago

Nowjs seems to have a replication system baked in with harmony proxies so when you update data structures these changes get pushed out to the clients. I chose to have dnode just make copies but I do plan on writing a replication middleware at some point with the .use() functionality that landed in dnode v0.5 so I'm interested to see how well this replication approach turns out with nowjs.

glesperance• 15 years ago

Blending this with browserify + backbone + redis will be really easy to do. I think it will definitely simplify the dev of our app ; allowing us to share even more code between the client and server so that we can maximize code reuse.

substack6• 15 years ago

On that note, (browserify author here) I would love to see projects like nowjs start to abuse the "browserify" field in the package.json for client distribution like dnode v0.6 does (presently in staging until socket.io-node v0.7 lands). With this field you can `require('pkgname')` in your browser-side code just by specifying 'pkgname' in your require list, even though pkgname might have both server and browser-side components.

sthatipamala5• 15 years ago

Sounds like it would be amazingly convenient. We'll definitely look into that for next release.

iag• 15 years ago

Great stuff Darshan!

dhruvbird• 15 years ago

Great stuff!! So, do you open up 2 channels? One for the client to make calls to the server (this could just be normal HTTP) and one for the server to make client calls?

sthatipamala5• 15 years ago

Depends. We're built on top of Socket.IO (http://socket.io/) which uses a websocket connection when possible. It falls back to assorted other transports if websockets are not available.

substack6• 15 years ago

And in the next release of Socket.IO Guillermo has promised us multiple channels, so projects like nowjs should get channels for free!

moe• 15 years ago

What about errors and exceptions? Will they propagate to the calling side?

ericz3• 15 years ago

In the typical node pattern, errors should be sent as part of the callback for asynchronous IO. For exceptions, a "throw" statement will not be automatically propagated to the other client, best practice is to catch the errors and call a client side function in that case. Exception handling will be improved in the future.

BobKabob• 15 years ago

Very cool stuff!

I'd love to see an example as to how you'd integrate that into a Python/Django project.

wampwamp• 15 years ago

redis.publish(some_listener, payload)

DenisM3• 15 years ago

All attempts to pretend that remote calls are local calls have failed thusfar. Chances are you will regret going down this route.

sthatipamala5• 15 years ago

Could you present some examples? We'd be interested to learn from the past.

DenisM3• 15 years ago

Sure: dcom, corba, rpc, soap. The lesson I learned is that you can't abstract away the network barrier; to the contrary - that barrier must be the central point of the design of storage and communication components of the app.

nimrody• 15 years ago

For some information on why Erlang did not go the RPC way:

http://armstrongonsoftware.blogspot.com/2008/05/road-we-didn...

brosephius• 15 years ago

n00b question here, but I installed it with npm and I'm trying to run the chat sample, but node says it can't find ../lib/nowServerLib.js

I'm still trying to figure out node so pardon my ignorance, but am I supposed to run this from a specific location? anyway, the project looks pretty cool, looking forward to playing with it.

Introducing NowJS or "How to make a chat server in 12 lines of code"

Related Stories