Мы говорим REST, а подразумеваем API, а говорим REST, а подразумеваем API, а говорим REST, а подразумеваем API, а говорим REST, а подразумеваем API, а говорим REST, а подразумеваем API, а говорим REST, а подразумеваем API...
res.write можно использовать сколько угодно раз, тут все зависит от того, какой стоит Content-Length и Content-Transfer-Encoding. pipe сам же делает res.write, и конечно упрощает жизнь, но не заменяет важности обработки заголовков.
В IAS есть встроенный механизм, который ретранслирует события между несколькими процессами на одной машине в режиме cluster и даже между процессами на разных серверах в режиме cloud. При чем, работа с событиями остается в привычном формате, тот же класс EventEmitter и методы emit и on, для отправки и подписки на события. Например, для бекенда: application.backend.emit('test', { data: 'data' }); и application.backend.on('test', function(eventName, data) { ... }); а для фронтенда application.frontend.emit('chat', { ip: client.req.connection.remoteAddress, name: client.fields.name, message: client.fields.message }); и все эти события автоматом пойдут в SSE пртокол на клиента.
Раньше для трансляции между процессами я использовал смешанный метод: IPC для одной машины и ZeroMQ для взаимодействия между серверами. Но недавно все переписал, абстрагировал транспортный слой и сделал три одинаковых по интерфейсу реализации транспорта: ZMQ, IPC и TCP. Теперь стало возможным сравнить их по скорости, оказалось, что TCP обгоняет всех в разы. Можете посмотреть как это все реализовано, там достаточно просто: impress.cloud.js и impress.cloud.tcp.js Там же есть и пример чата, который работает без комнат, но на многих серверах, тестируется в этом режиме вместе со всем сервером при каждом релизе.
Сколько будет максимум одновременных подключений? Сколько максимум комнат? Какая общая максимальная интенсивность сообщений? Не точные числа, а только порядок. Если 500тыс-2млн одневременных соединений, то это вообще все может быть на 1 машине, так проще масштабировать через cluster и делать обмен сообщениями между процессами через встроенный в child_process и стандартный для юникс систем IPC. Он в любом случае используется для передачи хендлов сокетов в cluster. Работает просто через process.send / process.on, см. https://nodejs.org/api/child_process.html Иначе нужно придумывать транспорт между серверами, это может любой способ передачи с установлением соединения и двухсторонним обменом, например, TCP сокеты, ZeroMQ, RabbitMQ, Redis, MongoDB. Все варианты бредовые, то что в голове каша, это правда. Уточните порядки цифр, если не нужно выходить за пределы одной машины, то не усложняйте, а если это проект класса ЗВИ (захавать все интернеты), то я посоветую другие решения.
Для всех доменов с www я рекомендую вместо того, чтобы отдавать копию сайта, делать переадресацию на такой же домен, только без www, чтобы не происходило дублирование страниц и еще прописать тег каноникал на него
module.exports = function(client, callback) {
if (client.host.indexOf('www.') > -1) client.redirect('http://' + client.host.replace('www.', ''));
callback();
};
В ноде настолько все иначе, что аналог Вам не нужен, а Вы думаете, что нужен. Лонг-пулинг для ноды, это как пробовать завести автомобиль при помощи кнута, по аналогии с лошадью.
Это я не из книги, а из своих заготовок взял, которые в ходе 20-летней практики организовались. Конечно проекты разные, но лучше иметь самый развернутый вариант и в зависимости от проекта просто выбрасывать из него те пункты, которые не подходят для случая.
Не волнуйтесь, это у них просто сериализация написана не через JSON.stringify, а строки клеят видать. Я бы рекомендовал порыться в коде, как они его пишут и читают. Может лучше у них поправить, а то вот так костыли и накапливаются.
Храним 100 в виде повышенной точности до сотых, т.е. 100*100 = 10000. Теперь делим это на 3 так Math.round(10000/3) получаем 3333 и выводим это для пользователя как 3333/100. Получаем 33.33 - это правильный результат с точностью до сотых. Не 33.34, а 33.33. При чем, деля на 100 для вывода можно не бояться получить длинную дробь, уже все округлено, чтобы деление свелось просто к установке точки в нужном месте.
Я не уверен, понимаю ли я, что Вы имеете в виду под "процентами от числа". По моему, любой процент это результат умножения на дробное число, а значит, что результат этого умножения нужно будет округлить и хранить с известной точностью в том же типе "number".
Ну слава Аллаху! А ежели мнго асинхронных выховов, то есть библиотека https://github.com/caolan/async которая позволяет собрать все вызовы и последовательно и параллельно и смешано
parallel тоже можно сделать по хешу именованных функций, а не по массиву. Ни то ни то не более и не менее правильно. К обработке ошибок это вообще ни малейшего касания не имеет, обработка ошибок одинаковая в обоих случаях: ошибки возвращаются из функций через колбэки первым параметром и попадают в первый параметр финальной функции. Разница только в том, будет ли async сам собирать данные в один хеш или мы запишем данные в свою структуру. Переменные items_list и user_list они же не глобальные, поэтому есть полная уверенность, что они не будут изменены где-то во время запроса. Выносить переменные за функцию, которая их изменяет можно и нужно. JavaScript построен на иерархически вложенных контекстах, которые порождаются функциями и модулями (файлами). На самом деле, конечно, только функциями, а модули при загрузке через require оборачиваются автоматом в функцию, экранирующую контекст модуля от остального приложения. Так вот, совершенно нормально, если переменные будут объявлены в одном контексте, то могут быть изменены в любом вложенном в него. Другими словами, если есть функция, объявляющая переменную, и внутри этой функции определена так же и вложенная функция, то вложенная может изменять все переменные наружной. Это нормально, не нужно стараться в JavaScript сделать "чистые функции", как в языках исключительно функциональных.
