Hot Code Push NodeJS

Question

I\'ve been trying to figure out this \"Hot Code Push\" on Node.js. Basically, my main file (that is run when you type node app.js) consists of some settings, config

Answer 1

Deleting require's cache doesn't actually "unload" your old code, nor does it undo what that code did.

Take for example the following function:

var callbacks=[];
registerCallback = function(cb) {
    callbacks.push(cb);
};

Now let's say you have a module that calls that global function.

registerCallback(function() { console.log('foo'); });

After your app starts up, callbacks will have one item. Now we'll modify the module.

registerCallback(function() { console.log('bar'); });

Your 'hot patching' code runs, deletes the require.cached version and re-loads the module.

What you must realize is that now callbacks has two items. First, it has a reference to the function that logs foo (which was added on app startup) and a reference to the function that logs bar (which was just added).

Even though you deleted the cached reference to the module's exports, you can't actually delete the module. As far as the JavaScript runtime is concerned, you simply removed one reference out of many. Any other part of your application can still be hanging on to a reference to something in the old module.

This is exactly what is happening with your HTTP app. When the app first starts up, your modules attach anonymous callbacks to routes. When you modify those modules, they attach a new callback to the same routes; the old callbacks are not deleted. I'm guessing that you're using Express, and it calls route handlers in the order they were added. Thus, the new callback never gets a chance to run.

---

To be honest, I wouldn't use this approach to reloading you app on modification. Most people write app initialization code under the assumption of a clean environment; you're violating that assumption by running initialization code in a dirty environment – that is, one which is already up and running.

Trying to clean up the environment to allow your initialization code to run is almost certainly more trouble than it's worth. I'd simply restart the entire app when your underlying files have changed.

Answer 2

Meteor solves this problem by allowing modules to "register" themselves as part of the hot code push process.

They implement this in their reload package:

https://github.com/meteor/meteor/blob/master/packages/reload/reload.js#L105-L109

I've seen that Meteor.reload API used in some plugins on GitHub, but they also use it in the session package:

https://github.com/meteor/meteor/blob/master/packages/session/session.js#L103-L115

if (Meteor._reload) {
  Meteor._reload.onMigrate('session', function () {
    return [true, {keys: Session.keys}];
  });

  (function () {
    var migrationData = Meteor._reload.migrationData('session');
    if (migrationData && migrationData.keys) {
      Session.keys = migrationData.keys;
    }
  })();
}

So basically, when the page/window loads, meteor runs a "migration", and it's up to the package to define the data/methods/etc. that get recomputed when a hot code push is made.

It's also being used by their livedata package (search reload).

Between refreshes they're saving the "state" using window.sessionStorage.