С таблицей будет куча проблем:
1. Ее нужно поддерживать в актуальности, а если процесс, породивший сокет, уже вылетел, то в базе будут неактуальные ID.
2. Когда у одного пользователя есть несколько устройств или открытых окон, то у него будет несколько ID, понятно, что в базу запишется последний, он затрет все предыдущие и работать будет только последний подключившийся клиент этого юзера.
3. Откуда мы узнаем, в каком процессе ноды нужно отправлять сообщение, если в базе есть ID, но нету идентификатора процесса? Получится, что все процессы будут пробовать отправлять вновь пришедшее сообщение. Вы вообще ноду в многопоточном режиме (cluster) запускаете? На одной машине или на нескольких?
А в чем более общая задача? Вы хотите рассылать всем пользователям одно сообщение и для этого нужна таблица? Для широковещательных есть socket.broadcast.emit(eventName, data);
А в чем трудозатратность? С ZMQ будет не больше строк, чем с базой, а IPC вообще встроенное решение, если в пределах одной машины то подходит. Если с ZMQ напряжно разбираться, то передавайте сообщения по редису. Вам же все равно нужно пересылать сообщения между процессами, вот только общая таблица ID не нужна.
Хранить в памяти другого процесса накладнее, туда еще обращаться нужно через TCP/IP. Взаимодействие между процессами ноды все равно будет, от этого не уйти. Но так у нас каждый процесс будет получать сообщение и искать внутри своей памяти по хешу, не по всему, а только по своему небольшому, т.е. выполняет часть задачи. А если делать через общую таблицу да еще и во внешнем процессе. В добавок к передаче сообщения между процессами, мы еще добавляем поиск по этой таблице (тоже с обращением в другой процесс по TCP/IP). Межпроцессовое же взаимодействие в ноде можно сделать через IPC (child_process, cluster) если в рамках одной машины или ZMQ, это будет значительно быстрее.
setTimeout в отдельном потоке (через fork) значительно надежнее, потому, что в основном потоке может происходить много всего, обработка HTTP запросов или TCP сокеты, там могут появляться исключения, что угодно, и тогда процесс свалится и setTimeout уже не вызовется.
Прототипировать на ноде просто, а написать серьезный долгоживущий код корпоративного уровня, который проживет 10 лет и будет 100 раз доработан и интегрирован - можно, но очень сложно, во всяком случае, все общепринятые нодовские инструменты не предназначены для этого, для этого плохо подходят такие антипаттерны, как Middleware, REST, MVC, CRUD и прочая ересь. См. habrahabr.ru/post/204958
А откуда Вы взяли, что это антипаттерн? Это замечательная возможность: состояние быстро меняется в памяти, без I/O вообще, это на несколько порядков поднимает производительность. Но его нужно сбрасывать в постоянное хранилище, конечно же, а это можно делать в ленивом (lazy) режиме, т.е. запросы ничего не ожидают, а когда появляется свободное время у системы, то можно сохранить все накопленное. Это укрупняет (консолидирует) запросы к БД и диску, т.е. может накопиться 20 изменений и они одним разом будут сохранены. Чтобы накопление не затянулось, можно устроить обязательный сброс не реже чем раз в N секунд (подобрать по нагрузке, например, раз в 30 секунд).
Ну конечно, data при работе с файлами это не String, а Buffer, см. nodejs.org/api/buffer.html В доках по библиотеке fs это конечно как-то смутно написано, полунамеками.
VorVanill тогда не native js, а pure js - чистый. Almik Эх! Дайте мне гитару если бы не было альтернатив, то Gmail, Facebook, Office 365 и т.д. тоже были бы написаны на extjs
Только если Вам уже ASP осточертел наконец, тогда стоит ) Я ушел в Node.js с C#, PHP, браузерного JS и более чем доволен. Попробуйте, для сравнения хоть.
1. Ее нужно поддерживать в актуальности, а если процесс, породивший сокет, уже вылетел, то в базе будут неактуальные ID.
2. Когда у одного пользователя есть несколько устройств или открытых окон, то у него будет несколько ID, понятно, что в базу запишется последний, он затрет все предыдущие и работать будет только последний подключившийся клиент этого юзера.
3. Откуда мы узнаем, в каком процессе ноды нужно отправлять сообщение, если в базе есть ID, но нету идентификатора процесса? Получится, что все процессы будут пробовать отправлять вновь пришедшее сообщение. Вы вообще ноду в многопоточном режиме (cluster) запускаете? На одной машине или на нескольких?