One issue with this approach is that the author is allowing users to start the background work, rather than putting it into a queue like he had been doing with his prior site. If his site gets slammed, this will be a problem, whereas with a queue he could set up his interface to let the user continue browsing the site while his/her work makes its way through the queue.
A queue would be a nice addition before the site goes live (it might be possible to employ a Redis list to do the job).
I'd love to see how far NodeJS could cope without the use of a queue though. I'm still something of a NodeJS novice but I'd guess that reading/processing every chunk inside a process.nextTick() callback would cause more disk IO problems than memory ones.
When I get the app running I might do some load-testing, the results would be very interesting.
Just curious, but does that implementation use the native websocket if possible, and then falls back on Flash if needed? I am interested in such a framework.
Why is switching from rb to js to get server side event-driven code better than using a rb library like EventMachine? Or is there another benefit of node.js that I didn't pick up?
My only problem in the past about using Ruby for this type of task has been memory usage and stability of long-running processes, but since I started using Ruby Enterprise Edition things are much improved.
Before I switched, I would typically have to log into the server several times a week to restart the Workling processes. I switched to REE a couple of months ago, and I just did a 'ps aux' on my server: the processes have now been running for over a month without a problem.
Also there is something rather appealing about using Javascript on both sides of the server/client divide. It's really very natural feeling.
I agree though, that EventMachine is potentially another option.
I've recently become a little nervous about the way that people are leaping for Node.js when there are proved libraries in pretty much every other language that are basically Node.js, plus five to ten years refinement and testing, plus numerous other plugin libraries that have been created, refined, and tested too.
If playing with the latest prettyshiny is your goal, have at it and have fun. But for getting real work done on real sites I have a hard time believing it's the best choice.
(If it seems simpler than the existing tech, that's the usual way of things. New tech like this is always simpler. It will eventually be discovered by the Node.js community that the complications present in EventMachine or Twisted or other competition is in fact not there because the developers are stupid, but because they learned the hard way it's necessary complication, for the most part, if you want the stuff to actually work, and in another couple of years, Node.js will end up being just as complicated and for the exact same reasons. If you don't mind not working in JS, you can skip to the end of this process if you pick up one of the other libraries that are already mature.)
I suppose that one of the advantages of NodeJS is that it can learn from the successes/mistakes of the others. Without having 5-10 years of cruft, baggage and backward-compatibility to worry about.
I take your point though. I only know EventMachine a little, and I've never used Twisted. And there's other solutions too. Pick the right tool for the job.
I'd love to know this too. I have a need for something similar to this situation and I'm interested in what he's doing. I would love to see some example code on how the file upload actually works.
One nice find from the article is the link to the Flash implementation of websockets: http://github.com/gimite/web-socket-js