rvagg

/me takes a bow You're welcome

Yuk, this is terrible. Please use the source of this data: https://nodejs.org/download/release/index.json or https://nodejs.org/download/release/index.tab, same URL works if you replace "nodejs" with "iojs" if you want to include the io.js versions as well. Use https://github.com/rvagg/node-version-data to grab it all programmatically if you have use for it.

This is such a silly meme. It IS a high performance data store, forget what you THINK it is/was designed for or what people say about it in that respect, rely on actual data to see if it works for your data & load. There's no competition if you want to compare it to an external data store it'll beat the alternatives easily. Comparing to other embedded data stores and the 2 main forks (basho and HyperDex) and alternatives like MDB is a different matter and this is where the nature of your data, the way you access the store (single thread? multi?) and your real load are much more relevant than heresay and benchmarks that bear no relation to your actual needs.

Worker Farm uses complete child processes with data-channel communication (via a pipe, as provided by Node's child_process.fork()). So, in terms of computing performance it should be pretty good but the communication may start letting you down if you're throwing lots of data around.

The main benefit is in the simplicity and durability, but don't use it unless you have a good use-case for it that goes beyond what a single Node process affords you.

Instead of moaning about usability here on HN, perhaps you should put in a pull request for all your brilliant changes to the UI and they will be considered.

MODERATOR CASISM, IT WAS CAPSLOCKSCRIPT

FWIW I initially went into ELB assuming it would solve a lot of my redundancy problems. And while it has helped a lot (I spread my frontend across 3 zones), I've suffered through a number of ELB failures or disruptions, including this latest one, which is one of the worst. Even with fully functioning servers that I can connect to individually, ELB was intermittently rejecting connections and failed to reregister instances. There's no silver bullet! Just prepare for failure and attempt to handle it gracefully, learning from each one. I suppose you should also think hard before you launch into a greater AWS budget to increase availability. Most of us are tempted to do that after each major incident--which is why Amazon can walk away from these events in a better position than before (until they have a genuine competitor that is).