Сервисы не мои, но меня поразило обилие информации:

• passports.io - сравнение возможностей проживания и получения гражданства в разных странах
  
• incorporations.io - сравнение стран для создания компании, налоги, отчётность, легальность итд
  
• bankaccounts.io - сравнение банков для открытия "международных" счетов
  
• flagtheory.com - разложенные по полочкам планы как уйти в офшор
  

Советую использовать последний стабильный релиз из ppa:

sudo add-apt-repository ppa:chris-lea/node.js
sudo apt-get update
sudo apt-get install python-software-properties python g++ make nodejs

npm идет в одном пакете с nodejs

Подробнее в официальной документации: https://github.com/joyent/node/wiki/Installing-Nod...

Прошёл год, написан и используется свой логгер. Ниже хочу описать причины и что получилось.

Требования поменялись и в настоящее время они отлично ложатся на идеологию 12 factor app 12factor.net/logs

А именно: логгер и само приложение не занимаются записью лога ни в файл ни в базу. Никаких транспортов. Лог пишется только в stdout.

Мотивация:
1) Мы получаем отличный лог в консоле во время разработки просто запустив приложение. Без всяких "девелоперских" режимов транспортов.
2) В продакшене сбором и транспортом лога занимается то, что запускает наше приложение (forever, upstart, supervisor). Процесс транспортировки лога лежит не на самом приложении - это развязывает руки в использовании как своих сервисов агрегации логов (logstash), так и сторонних (loggly).
2) Как логгер, так и само приложение избавлены от багов "толстого" логгера и транспортов.

Требования к реализации:
1) Быстрый старт - возможность начать использовать логгер без первоначальной конфигурации
2) Пространства имен
3) Гибкость в настройке формата сообщений (которые мы пишем в stdout)

Вот так получился mag логгер

Быстрый старт

var logger = require('mag')();
logger.info('my great application is running!');

Пространства имен

var mag = require('mag');
var logger = mag('my-app');
logger.info('my great application is running');

Настройка формата сообщений.
Мы можем подключать mag сколько угодно раз, даже в подмодулях. Подключив один раз модуль mag-hub - все сообщения пойдут через него. mag-hub - это стрим в режими объектов. Мы можем читать из него и делать с объектами логов всё что угодно, записав потом в stdout конечно.

При написании подмодуля приложения о логировании заботиться также не нужно: https://github.com/mahnunchik/mag#for-module-developers

Ссылки:
1) mag logger
2) API логгера
3) Модуль агрегации логов в одном стриме mag-hub

Если появилось желание написать свой кэш, то стоит сделать шаг назад и ещё раз подумать над архитектурой.

Ответ: Локально кешировать результаты из монги однозначно не стоит.

А теперь подробнее:
В монге кэш достаточно хитрее чем сохранение последнего результата. (docs.mongodb.org/manual/faq/fundamentals/#does-mon...) Мога может хранить в оперативке только индексы и прирост в производительности "кеширование" происходит только когда все необходимые запросу поля входят в индекс, а индекс в свою очередь в оперативке после предыдущего запроса к этой же коллекции.

Варианты решения:
1) Если данные меняются часто (минуты) - то как вариант монга, соответственно без "своего" кеширования. Но если данные (строки локализации, меню) ложатся на структуру ключ/значение, то целесообразно использовать что-то более предназначенное для "быстрого" чтения типо redis или при мультинодовой архитектуре то etcd
2) Если данные меняются редко (дни) - то обычные файлы с локализациями (загрузка при старте апы) будут оптимальным вариантом=)