dotCloud now has beta websockets support, so this hack should no longer be necessary. Just point your custom domain to experimental-gateway-1.dotcloud.com instead of gateway.dotcloud.com and you will be using a websockets-aware load balancer instead of the default one running Nginx.

Most web hosts with node.js support host it behind an nginx proxy. Sadly, Socket.IO doesn’t work at all behind nginx without a bit of hacking. Currently there’s no vhost-supported way to run websockets through nginx, but we can at least get the xhr transport to work properly–basically everything can do xhr-polling.

Turns out that nginx doesn’t really like how Socket.IO uses the “Connection: keep-alive” header, so lets just remove that. All we need to do is overwrite a function in the xhr-polling transport. This should do it;

io.configure(function() {
  io.set("transports", ["xhr-polling"]);
  io.set("polling duration", 10);

  var path = require('path');
  var HTTPPolling = require(path.join(
    path.dirname(require.resolve('socket.io')),'lib', 'transports','http-polling')
  );
  var XHRPolling = require(path.join(
    path.dirname(require.resolve('socket.io')),'lib','transports','xhr-polling')
  );

  XHRPolling.prototype.doWrite = function(data) {
    HTTPPolling.prototype.doWrite.call(this);

    var headers = {
      'Content-Type': 'text/plain; charset=UTF-8',
      'Content-Length': (data && Buffer.byteLength(data)) || 0
    };

    if (this.req.headers.origin) {
      headers['Access-Control-Allow-Origin'] = '*';
      if (this.req.headers.cookie) {
        headers['Access-Control-Allow-Credentials'] = 'true';
      }
    }

    this.response.writeHead(200, headers);
    this.response.write(data);
    this.log.debug(this.name + ' writing', data);
  };
});

A handy middleware utility for node.js and express to queue scripts and styles to be rendered later. Supports supplying javascript via anonymous functions to avoid multi-line string issues and also has built-in minification, which can be enabled when you render the scripts.

Chattan

This is the expanded source of the chat demo I made for my Node.js presentation at OKDG. I added CouchDB user persistence, S3-backed file uploading and also inline media embedding via another open-source project of mine called Embedify.

Jquery-droploader

A jquery plugin for xhr-based upload management with support for drag-and-drop regions. I used this for handling file uploads to S3 in Chattan.

Not only that, the chat demo created in the presentation will remain live for all to play with. In addition to what was covered in the presentation, it also has a basic message filtering system to convert URLs to embedded content. Try posting a URL to an image, Youtube video or PDF and you can see it in action. Check it out!

Download as PDF

Using this amazing new system I was able to integrate support for the new WebSockets specification that Google recently added support for in Chrome, and I used this to make a simple real-time chat application with emoticon support and translation of image links to inline images and youtube links to inline videos.

…and the best part? This only took me about an hour!

There are some simple architectural differences that make it vastly more powerful that most any other popular web programming languages. One of my favorite characteristics of it’s unique design is that variables assigned in a global scope can be accessed across all requests…that means regular database querying becomes completely unnecessary! You could create a json object where you store your data, then check it over every once in awhile, and apply any changes to the database. It’d work as a query queue of sorts that would greatly reduce database interaction overhead and it wouldn’t require setting up some other incredibly complex software to proxy the requests!

I’m also quite fond of the branching design. There is a module called ‘http’ for running web servers, but it’s really just routing everything through the tcp module, which essentially does the same thing. The ‘http’ module just simplifies the interface and makes common actions like sending headers more elegant. It’s a clever design really; supply varying levels of complexity in control to match varying levels of complexity in application–not everyone is going to want the ability to create a mail server, so why would they want to have to access tcp directly? Inversely; not everyone is only going to want a web server, so why would you only supply access to http-related code?

Have a look at this sample code I ripped-off from the homepage of node.js;

var sys = require('sys'),
   http = require('http');
http.createServer(function (req, res) {
  setTimeout(function () {
    res.sendHeader(200, {'Content-Type': 'text/plain'});
    res.sendBody('Hello World');
    res.finish();
  }, 2000);
}).listen(8000);
sys.puts('Server running at http://127.0.0.1:8000/');

Isn’t it so simple? You just include a few modules, run http.createServer() with a callback function passing in the request and response objects and tell the server to listen on whatever port you want and whatever domain you want. In the callback you can branch of by breaking apart request.url to find the user’s query and use that to redirect via a switch block or whatever other means you see fit. Best of all, it’s asynchronous, so you don’t need to halt execution for every little thing. It’s even compatible with many common Javascript utility libraries such as Underscore