Ryan Tomayko

Digging Deeper with htracr —

Node.js based packet sniffer and visualization frontend for observing how HTTP requests are interacting at the TCP level.

Heroku Ships Experimental Node.js Support —

Boom. It looks like long running connections aren’t completely baked yet but this is really promising.

Node.js, redis, and resque —

Interesting use of node.js as a sort of HTTP reverse proxy. It uses redis based queues to communicate with backends instead of establishing a direct socket connection and doing HTTP:

This spike uses node to put messages into a (redis) queue. Ruby background workers read from the queue, process the requests, and respond on a different queue. When node receives the response from the background worker, it sends the response back to the waiting user.

I assume this adds a not insignificant amount of latency to each request but would also make possible a bunch of long-running connection features. For example, the response (or portions of the response) could be delivered from separate worker processes. This style of architecture, where the client connection isn’t tied to backend web process, looks promising. The nginx_http_push_module is another example that gives the same types of benefits.

How do we kick our synchronous addiction? —

Eric Florenzano asks why modern web frameworks insist on a synchronous programming model and gives some answers with possible alternatives. The article is dead on, IMO, but I’m not sold on his conclusion:

We need to look at these alternative implementations like coroutines and lightweight processes, so that we can make asynchronous programming as easy as synchronous programming.

For Ruby, this is all about making Fiber robust and widely available. There was a time when I too thought this would solve all problems by hiding the underlying async model but retaining its benefits. That’s the dream. I don’t believe in it anymore. Having experimented with such an approach on a small team, I’m fairly confident that everybody working on an event-based/async program needs to understand the underlying model or blocking code will inevitably be introduced and destroy everything. And once everyone’s comfy with async, you’ll find that the sync façade is annoying and unhelpful. Embrace it.

How would you serve 100,000 simultaneous comet requests with Node? —

Simon Willison throws down a C100K problem for node.js. That’s a tough order for a single machine. To get even close, you’re going to need lots of system tuning way down below node.js.

Node.js For My Tiny Ruby Brain: Keeping Promises —

Rick documents his progress a week into node.js. Nice look at some of the basic concepts underlying the system, like async everywhere and promises.

Server-Side Javascript: Back With a Vengeance —

Nice to see Narwhal, Jack, CommonJS, and node.js getting some love on ReadWriteWeb. Javascript on the server is breaking out.

Video: Node.js by Ryan Dahl —

ry’s talk from JSConf.eu. The leading paragraph says it all:

Node.js might be the most exciting single piece of software in the current JavaScript universe. Ryan received standing ovations for his talk and he really deserved it!

Wow. JavaScript is pretty damn big universe right now.

Node.js is genuinely exciting —

I agree. I played with it for a couple days and now I can’t shut up about it. That’s basically all I talked about at RubyConf :)

ANN: node.js (JavaScript) BERT-RPC implementation: node-bertrpc —

I’ve released a bertrpc library for node.js. If you haven’t play with node yet, set aside a night and dig in. Hacking async server-side stuff in JavaScript is every bit as awesome as I’d hoped: easy to install, good docs, fast VM, clean and simple event idioms. I’m impressed.