Hacker News Reader

Comment by euroclydon | Hacker News Reader

Since this is near the top of the HN page, I'd like to ask a question about node.js:

What is it suited for? I read the about section of the node.js homepage, and it says that "Node's goal is to provide an easy way to build scalable network programs." Okay, that sounds cool, and I like Javascript, so I want to see if I can fit it into any projects I'm working on, but then I go on to read: "Almost no function in Node directly performs I/O." Okay again, single thread, no I/O, I can see why it's fast. But what if I need I/O, like from a DB? Does that mean I should not use node.js? What is a suitable method to store and transport data when using node.js? MemCache?

View on HN

Database adapters for Node are beginning to show up - there's an async PostgreSQL one and I think there's one using libdrizzle (which should work for MySQL as well). Since Node speaks HTTP fluently it's great for talking to things like CouchDB, and there's also DBSlayer http://code.nytimes.com/projects/dbslayer which provides an HTTP API for running MySQL SQL queries.

Node + Redis is an awesome combination.

Don't forget APIs - if your application simply hits a bunch of HTTP APIs from other providers (mashup style) Node is a great fit.

Thanks for the shout-out in the slides about the Redis client for Node.js.

http://github.com/fictorial/redis-node-client

The important word in that sentence is "directly". There are plenty of ways to do I/O in node, but they generally involve event-based callbacks so that they don't block the thread.

Are there any special considerations for keeping the TCP connection open while the thread is waiting for the callback? I'm assuming no, since node.js doesn't seem to exist in order to facilitate long running requests.

I'm not sure, but I'd guess closing over it in the callback would work, as long as the TCP timeout is longer than the database response (even then, you could probably touch the stream every so often while you wait, perhaps via nextTick or something).

I don't really have a direct answer to your question, but the somewhat official demo for node.js is a chat server that uses http long polling to push messages out, so node can definitely handle that.

Node is designed specifically TO facilitate long-running requests. There is only one thread (it's a single-threaded, evented system). Everything is done with callbacks, so if you have a long running I/O operation you'll just add a callback which completes the current HTTP response when the long-running I/O has finished. Node is quite happy to keep thousands of such callbacks around at once for massive concurrency.

Since Node scripts are persistent (i.e. aren't created and destroyed for each request), it doesn't care how long or how many connections are open. It's ideal for long-running requests.

The core of Node has very few functions that perform I/O, but there's no reason you can't use I/O in your own programs (in the original link, the network stream is read and written out, and also the blacklist file is read, synchronously). The readFileSync call is an anomaly in Node - typically you use evented I/O - open a stream and set listeners/callbacks for particular events.

There are modules developed for most of the major open source databases (I'm not sure what the status of the async MySQL driver is, but there's definitely something you can use).

I suppose I should chime in and say that I am not exactly sure what Node.js's about page is talking about when it says 'I/O'. Could someone clue me in as to what exactly this means?

Reply on news.ycombinator.com