Виталий

имхо виф рекурсив в купе со связкой ид, кей, парент_ид, маршрут_ид куда более удобны в обслуживании...

привет тайпскрипт
декорированный экспресс https://github.com/typeorm/typeorm-routing-control...
депенденси инджекшен https://github.com/typeorm/typeorm-typedi-extensions
ОРМ (есть разные модели. есть каскады, забираешь каскадную модель с релейшенами, апдейтишь все что тебе надо. говоришь сейв, оно транзакционно пишет твои правки) https://github.com/typeorm/typeorm
авторизация через jwt
наложение ацл можно решить через декораторы или мидлвары
sails.js не юзай, труп оно

nodejs на сервер сайд еще не всегда популярное решение, но я голосую за ts на беке, или js + flow

дружище, не вкурил ты доку
смотри как решать это, вешаешь

io.on('connection', function (socket) {
  socket.on('join', function (from, msg) { ожидаем с клиента emit('join', 'channame')
    socket.join(msg); // msg = channame
    socket.to(msg).emit(`client ${from} connect to chat`);
  });

потому что сервер отдает заголовок ориджин в котором нет имени твоего сайта и система безопасности браузера рубит твои запросы.

впн тебе поможет

все просто
идешь за любым учебником по скуль, читаешь его, применяешь знания
твой вопрос кроется в связи 1 ко многим, удачи в изучении.

можно пойти по пути какой-то из dependency injection

const consoleLog = console.log
console.log = (...args) => {
    // то что ты хочешь с аргументами делать
    consoleLog(...args);
}

аналогично для error
важный момент это надо цеплять в прелоад в браузере на нужные тебе страницы.

request = request.defaults({'proxy':'http://localproxy.com'})

достаточно просто открыть документацию модуля

есть в протоколе соответствующий заголовок для паролей, называется authorization
есть basic авторизация, это там где логин и пароль вроде бы разделены двоеточием (точно не помню, но легко гуглится) и обернуты в бейс64, ты просто почитай документацию на эту тему. Зачем городить что-то от себя, когда есть рфц?

$ is not defined как бээээ

неймспейсы, румы? в чем проблема то?
если требуется разделить логику разных процессов в чем минус нескольких сокет серверов?
какой-то риторический вопрос имхо

Телеграф жс

Потратить два дня и изучить да, не смеши вопросом.

1. чаты делятся на комнаты, реализуешь протокол, можно типо ирц. Например есть на сервере подписка request:join
Когда твой клиент решает войти в определенный чат, он делает отправку запроса на сервер emit('request:join', roomName); на сервере есть реакция, обработка можно ли клиенту присоединиться к этому чату или нельзя.
2. в обработке события на сервере у тебя идет on('request.join', roomName=>socket.join(roomName); В этот момент надо перебрать все активные сокеты, на предмет того, используется ли клиентом второе окно (если это требуется конечно).
3. По этому принципу можно строить и общие чаты, и приватные. Люди начинают общаться не друг с другом, а писать в канал. клиент пишет emit('message:send", {room: id, message}), на сервере это пересылается в рум как .on('message:send', message=> io.to(message.room).emit(message.message)
В результате получается что клиенты общаются между собой, но по факту лишь шлют все данные своему серверу, а он уже принимает решение уведомить об этом остальных или нет.