Тимур Шемсединов

Так можно же посмотреть, как написан тот же модуль fs: https://github.com/joyent/node/blob/master/lib/fs.js
Как писать асинхронные функции Вы нашли, код нормальный, а вот асинхронный модуль - это нонсенс, вот модуль fs синхронный или асинхронный? Ведь в нем есть fs.readFile и fs.readFileSync. Модуль может содержать и синхронный и асинхронный код, вообще в ноде асинхронно решается обычно только ввод-вывод: работа с файлами, сетью, базой данных. Весь остальной код остается синхронным. Чувствуется, что Вы еще не полностью освоили ноду, а уже хотите делать свои модули. Рекомендую Вам перед этим почитать исходники хороших модулей, например, вот этих небольших и хорошо написанных:
https://www.npmjs.com/package/mkdirp
https://www.npmjs.com/package/ncp
https://www.npmjs.com/package/colors
Советую пройти nodeschool.io/ru и потренироваться в использовании модулей, а потом уже делать свои. Еще обязательно освойте библиотеку async: https://github.com/caolan/async и посмотрите что такое EventEmitter https://nodejs.org/api/events.html Ну и конечно читайте исходники ноды и других модулей. Статей же нагуглить или на Хабре нарыть - не должно быть проблемой.

Проблем при разработке не возникнет, они возникнут при масштабировании за пределы одного сервера. Если очень больших нагрузок не планируете, то не парьтесь и пишите как попало. На мобильных платформах: socket.io/docs/faq Масштабирование в пределах одного вервера: socket.io/docs/using-multiple-nodes Масштабирование за пределы одного сервера: нужно связывать процессы через шину событий ZeroMQ, Redis, RabbitMQ и т.д.

return ((crc & 0xFF) << 8) + ((crc >> 8) & 0xFF);

Потому, что нет функции, в которую вернется результат работы запроса, Вы скажете, какой результат у DELETE? А я Вам отвечу, что результат этот предусмотрен у connection.query и даже DELETE может вернуть ошибку, а если некуда ее вернуть, то нарушен формат вызова функции, она имеет полное право не работать. Кроме того, ради Аллаха, не клейте SQL строками.

var sql = 'DELETE FROM test WHERE id = ?';
connection.query(sql, [results[0]['id']], function (err) {
  if (err) console.log('Error query');
});

Клиент может быть как браузерное, так и оконное приложение (например на C#, Java, но это уже редко используется, разве что в тех случаях, когда клиентское приложение должно локально взаимодействовать с API операционной системы или оборудованием и должно выводить такую графику, как браузерное приложение не может, например в некоторых играх, где нужно плотно работать с видеокартой, а из браузера ее не достать), а браузерное приложение - тут уж в любом случае JavaScript. Если оконное, то хватит и IP для связи (пишем IP и порт в конфиг), а браузерное - гораздо удобнее его открывать через доменное имя будет. Между клиентом и сервером Вам нужно будет обмениваться данными, для этого нужно выбрать: протокол и формат сериализации. Независимо от того, будет ли клиент браузерный или оконный протокол лучше всего брать HTTP (его можно проксировать и масштабировать, к такому API потом проще будет обращаться из других приложений, когда понадобиться развитие системы). Но обычный HTTP это односторонний поток запросов от клиента к серверу, а может оказаться, что для задачи нужно и обратный поток, от сервера к клиенту, например, чтобы передавать события, которые происходят на сервере, если их вызвали другие пользователи или серверные задачи. Для трансляции событий нужен протокол с установлением соединения, т.е. такой, где связь поддерживается долгое время и сервер может прислать сообщение без запроса, т.е. чтобы клиенту не довелось каждые 2 секунды переспрашивать сервер, нет ли уже каких-то данных. Для этого подойдет SSE (Server-Sent Events) это расширение HTTP протокола, но он односторонний, от сервера к клиенту, а клиент все свои запросы отдельно должен присылать, делая HTTP GET/POST запросы. Можно так же использовать WebSocket, он двусторонний, и через него можно устроить обмен данными в обе стороны, но SSE гораздо проще в реализации и я советую именно его. Теперь нужно организовать API на сервере, я для этого советую Node.js, это мой выбор, а причины я поясняю тут habrahabr.ru/post/204958 Ну и выбрать СУБД, из реляционок рекомендую PostgreSQL www.postgresql.org а из объектных (документных) MongoDB https://www.mongodb.org/ Ну и если все компоненты подходят, то вот мой сервер приложений, в котором я уже все это собрал habrahabr.ru/post/247543

Ну... в Вашем случае, главное, чтобы инвестор не читал Тостер, а архитектуру можно сделать и после завершения проекта ))) А вообще моя лекция по архитектуре для ноды (но в ней есть много общих вопросов и полезных мыслей): https://youtu.be/Try7lmWikao И на Хабре есть специальный раздел "Анализ и проектирование систем" где проскакивают статьи по архитектуре, как например: habrahabr.ru/post/204958 Нарисуйте связь компонентов системы СУБД-сервер-клиент (трехзвенка, или больше компонентов, если есть), нарисуйте уровни по ISO/OSI, слои абстракций, дайте спецификацию API. Вот тут есть я даю расширенный план проектирования, он должен помочь: Как составить план проектирования проекта?

Передача хендлов сокетов в дочерние процессы тут находится во встроенной библиотеке cluster и скрыта от разработчика. Так же все процессы пишут и читают из редиса (см в коде вызовы incr/decr, zrem/zadd). Процессы подписываются на редисовские каналы (см в коде conn.on('message'...) и conn.on('subscribe'...) ). Код в этом репозитории уже три года не изменялся, масштабирование только на несколько процессов на одной машине, ничего уникального не написано, весь этот функционал сидит в редисе, будет тратиться много ресурсов, чтобы обеспечить межпроцессовое взаимодействие ноды с ним, даже не интересно смотреть эту реализацию. Это устаревший хлам, за три года нода уже изменилась, а как изменилась инфраструктура и возможности дополнительных пакетов...

Ничего сложного в этом нет, вот только рекомендую переместить переменные, или скорее это константы в /init/constants.js, а то ведь на /server/requests.js они каждый раз создаются и теряются. Например так:

application.constants = {
  'domain1.com': { field1: "value1", ... }
  'domain2.net': { field1: "value1", ... },
    ...
};

А в /server/requests.js их можно будет просто возвращать в зависимости от домена сайта:

module.exports = function(client, callback) {
  client.cache('10m');  // кешируем на 10 минут
  // отдаем нужный набр переменных для сайта
  callback(application.constants[client.host]);
};

Ну и в /config/hosts.js настраиваем все на одно приложение:
module.exports = [ '*' ];

Нет. Вам же нужно их обрабатывать, они же открытые TCP сокеты, в какую базу? У каждого сокета есть идентификатор и кусок памяти свой выделен на уровне операционной системы под буфер. Кроме того, из каждого сокета что-то приходит, и в него нужно что-то слать, это что тоже через базу делать? Похоже на то, что Вам нужно почитать про TCP/IP, про сокеты и про сетевое программирование хоть несколько статей, хоть бы на Хабре может. И Вам нужен cluster, чтобы распределить эти сокеты на несколько процессов, чтобы у одного действительно память не кончилась и чтобы занять другие ядра проца.

Кроме того, обратите внимание, что TCP - это не пакетно ориентированный протокол, а потоковый, т.е. если отправить 10кб данных одним разом, то они могут прийти одним разом, а могут подробиться как угодно, прийти за 4 раза, например, 1кб+3кб+4кб+2кб. Так же и склеиваться могут, если отправить подряд 5 фрагментов, то они могут склеиться в один. Более того, от одной посылки может отклеиться небольшая часть и приклеиться к следующей. Все, что TCP гарантирует, это то, что данные придут точно и в правильной последовательности.