Playing with real-time content delivery (WebSocket)

This time I'd like to share some results of experimenting with Firebase and Socket.IO while playing with real-time content delivery with WebSockets a bit.

FireBase - NoSQL database, has a powerful API to store and sync data in real-time using WebSocket. It also has perfect Security Rules system, which allows to restrict read and write access to data in the manner I was dreaming about when playing with CouchDB back in 2011. The goal was to let everyone access only his or her data right from the browser. So, here is an example of security rules that suites this need:

{
  "rules": {
    ".read": false,
    ".write": false,
    "users": {
      "$user": {
        ".read": "auth.uid === $user",
        ".write": "auth.uid === $user"
      }
    },
    "data": {
      "$data": {
        ".read": "auth.uid === data.child('uid').val()",
        ".write": "auth.uid === data.child('uid').val()"
      }
    }
  }
}

Then there are many ways to authenticate. With Simple Login, it could be static web site hosted on FireBase, similarly to CouchApp, fantastic! But I decided to try custom authentication, and integrate Firebase with Atlassian Connect Add-On in Node.js using atlassian-connect-express.

Here is relevant part of client javascript. That simple to get own data:

addon.js

  var rootRef = new Firebase("https://example-multi-tenant.firebaseio.com/data");
  rootRef.auth(firebaseToken, function(error) {
    rootRef.on("value", function(snapshot) {
      var data = snapshot.val();

And firebaseToken is generated serverside basing on authentication information provided by Atlassian Connect. So I map clientKey to uid for Firebase security rules:

routes/index.js:

    var FirebaseTokenGenerator = require("firebase-token-generator");
    var tokenGenerator = new FirebaseTokenGenerator(process.env.FIREBASE_SECRET);

    app.get('/whoslooking', addon.authenticate(), function (req, res) {

        var clientKey = req.session.clientKey;
        var firebaseToken = tokenGenerator.createToken({ "uid": clientKey });

I did not come to particular useful use-case yet, and have tried to clone existing Who's Looking add-on for JIRA, but there must be better ideas to try out with this approach.

For such simple case, it looked overcomplicated to me, so I've given Socket.IO a try, and ended-up actually within Engine.IO, which is the WebSocket semantics transport layer Socket.IO uses.

The main interesting part for me is authenticating connections, so that only add-on could connect. Here is the trick to leverage atlassian-connect-express authentication within allowRequest function that can decide whether to allow WebSocket request or not in app.js:

var authentication = require('atlassian-connect-express/lib/middleware/authentication.js');
var authenticationHandler = authentication.authenticate(addon, true);

var server = http.createServer(app);
var io = require('engine.io').attach(server, {allowRequest: function(req, next) {
  req.query = req._query;
  req.header = function(name) {
    return req.headers[name];
  };
  var res = {
    send: function(code, msg) {
      next(msg); // error
    },
    setHeader: function() {}
  };
  authenticationHandler(req, res, function(err) {
    next(err, !err); // success
  });
}});

Then Who's Looking logic itself is very simple. State is just kept in memory serverside, and is updated when connection is open or closed, and every time simple message is sent to client with all users currently looking at JIRA issue, no heart-beat (or long polling) and database. Nice and easy, isn't it?

Such add-on can be deployed to Heroku, by the way, it has support for WebSockets already!