Since you mention at the end you can live with missed writes, I do think this would be reasonable. A couple of thoughts which might make it more robust if you were going to rework it a bit. First, you could have the actual write process handle all pending writes when it runs. Second, and while this wouldn't catch everything, you could process.on('exit',writeOutstanding) or do the same with window.unload or the current preferred browser/cordova closing event.

Good thoughts - thanks!

I would definitely wrap this in something that looks/feels/behaves synchronous but hides its inner "asynchronisityishness." You just want to log; you don't want to deal with your logging tool handing you promises and stuff to deal with.

When building brackets-git project I run into a similar problem. The application is coded in a way that it considers Git to be async but that doesn't work well because Git works with a file system and fails when two executions are trying to lock the same files. So I had to hide this behavior implementing a promise queue (because we also care about the result, unlike the samples above). Looks something like this:

// actual git caller
function _git(...args) {  
  return new Promise(...);
}

const queue = [];
let queueRunning = false;
function runQueue(item) {
  if (item) {
    queue.push(item);
  }
  if (!queueRunning && queue.length > 0) {
    queueRunning = true;
    _git(...queue[0][1])
      .then(result => queue[0][0].resolve(result))
      .catch(err => queue[0][0].reject(err))
      .then(() => {
        // important, remove the item from queue and run it again
        queue.shift();
        queueRunning = false;
        runQueue();
      }
  }
}

function git(...args) {
  const deferred = Promise.defer();
  runQueue([deferred, args]);
  return deferred;
}

// and in the code just
git('status').then(status => ...)
git('log').then(log => ...)

For a problem like this check out Subjects and Observables in rxjs, instead of using promises. There is a great presentation on this by Jafar Husain at Netflix. If you haven't seen it I can Post the link.

What you want for something like this is a system with back pressure support. That way, you can pump messages in slow, fast, or in bursts. Then the observer can processes them as fast as it can. With Observables you can take messages one at a time, in batches, filter out messages, etc. There are a lot of options for working with the data coming through.

There are definitely situations where sending async calls to the background is a huge advantage. Such as sending an email after closing an http connection. This is a major benefit with aysnc I/O runtimes such as nodejs. Accomplishing such things in many languages can be painful.

My guess is this code is crashing because you are initializing and reading the length of the file on every single log call so this will consume cpu and memory exponentially.

If you open only one file descriptor you should be able to treat `fileWriter.write(blob);` as a queue in that the messages to the file will happen in the order it is called.

FWIW - I think this would make an excellent interview question as its very common "real world" scenario.

It isn't crashing, just writing data incorrectly. But I can see how it could crash too which is just another problem. :)

I'm fighting learning that. ;) My first encounter was with Angular2 and it felt overly complex. But so did Promises at first. At FluentConf, the most packed session was on rxjs.

It takes some getting used to, but now that I have I'm a big fan. I use them for my Actions and properties in my Stores in my reactjs app. Someday I'll write up a blog on it.

I can't help but share this video, I saw a version of this at a conference and it was the best session I've seen in a long time. https://youtu.be/5uxSu-F5Kj0