Skip to content

Concerns and Decisions

Alan Gutierrez edited this page Sep 18, 2010 · 3 revisions

Concerns and Decisions

Probably want to create a queue interface where people can queue up events that they want to have complete before they take action.

http://github.com/tsmith/node-control

Moving to CoffeeScript

Going to convert the library to CoffeeScript and proceede from there. Why CoffeesScript?

  • CoffeeScript emits the Good Parts of JavaScript and the output passes through jslint, so I can write quality JavaScript code without knowing how.
  • C syntax does not quite fit hand and glove with functional or object oriented programming. CoffeeScript has a nicer, seemingly Haskell like dialect.
  • Less code means more code.
  • I really don't like prototypical JavaScript. It is hard on the eyes.

Error Handling and API Call Pretty

I've decided to eschew sugar and checking in this library, since that would be a lot of tedious work. When there is a community willing to track issues and support patches, we can create methods for each of the commands. For now, it makes more sense to name the command.

    request.error(function (statusCode, struct) {
    });
    request.call("CreateVolume", { size: 160 });
    request.poll("DescribeVolumes", {}, callback (struct) {
    });
    request.complete(function () {
      console.log("Mounted and ready to go.");
    });

The call method will invoke one of the Query API commands. The poll method will invoke the query API command until the callback returns true. The latter method is for the common case of checking to ensure that an instance is running or a volume is attached before proceeding.

My concern about error handling is that errors cost money. I've used Amazon EC2 for nightly backups, where I've run an instance for a few minutes each night to extract backups from productions servers to EBS. This is inexpensive if the instance only runs for a 0.08USD a night. It is no longer inexpensive if an instance fails to shutdown and runs for the rest of the month. It is a pretty penny if every night, the instance fails to shut down and at the end of the month I notice a bill for 31 EC2 instances.

I've sweated this, but I prefer the notion of keeping the API as simple as possible so, to wind down, one could do the following.

    function launchBackup(callback) {
      var state = {};
      request.error(function (statusCode, struct) {
        if (state.instanceId) {
          termianteBackup(state.instanceId);
        }
      });
      request.call("RunInstances", { size: 160 }, function (struct) {
        state.instanceId = struct.instanceId; 
      });
      request.poll("DescribeInstances", {}, callback (struct) {
        var instance = struct.instanceSet.select(function (i) {
          return i.instanceId == state.instanceId;
        });
        if (instace) {
          successful.runInstance = true;
          return true;
        }
      });
      request.call("AttachVolume", { size: 160 });
      request.poll("DescribeVolumes", {}, callback (struct) {
        
      });
      request.complete(function () {
        console.log("Mounted and ready to go.");
      });
    }

Basically, if you are going to use the queue, you can create a closure to track the progress through the queue and shutdown your instances in the error.