Можно ли так делать в socket.io node.js?

Question

[moon_and_altair]

Хочу разделить большой файл обрабатывающий сокеты на маленькие кусочки. То есть с:

module.exports = function (io) {
    io.on('connection', function (socket) {
        console.log('+');
        socket.emit("sessiondata", socket.handshake.session);
        socket.on("login", function() {
            socket.handshake.session.user = {
                username: "OSK"
            };
            socket.emit("logged_in", socket.handshake.session);
        });
        //И так далее
    });
};

на:

module.exports = function (io) {
    io.on('connection', function (socket) {
        require('./lib/connection')(socket, io);
        require('./lib/login)(socket, io);
         });
};

Получается 2 вопроса.
1) можно ли так делать?
2) можно ли делать

require

без задания переменной

var

?

Answer 1

[vsvladimir]

Можно, насколько это хорошо зависит от задачи. Например может потребоваться что-то общее делать и уведомлять об этом все модули.

Answer 2

[Кирилл]

Не красиво же. IMHO не надо размазывать require по коду - читабельнее когда все зависимости в одном месте прописаны.

var connection = require('./lib/connection');
var login = require('./lib/login');

module.exports = function (io) {
  io.on('connection', function (socket) {
    connection(socket, io);
    login(socket, io);
  });
};

Answer 3

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

Делать require без присвоения в переменную можно и нужно, но только не внутри события connection, потому, что require исполняется синхронно, это блокирующая операция, т.е. на каждом подключении будет выполняться код, который будет приводит к чтению файла, а при этом не отдает управления в eventloop. Лучше поместите io на старте в глобальную переменную типа

global.api = {};
api.io = require('socket.io')(80);
api.events.connection = require('./lib/connection');
api.events.login = require('./lib/login');
...
api.io.on('connection', api.events.connection);

А в файле /lib/connection.js написать:

module.exports = function (socket) {
  socket.on('login', api.events.login);
  ...
});

Comments

[Кирилл]

require кэшируется - блокирующая операция чтения файла будет только при первом обращении.

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

Кирилл: кешируется не всегда, если модуль ничего не вернул в module.exports, то он не закешируется, а тут человек просто на грани отказа от классического DI. Модуль же может и сам себя пихать в глобальную переменную api.events.connection = function(socket) {...}; И это прекрасно. Но require не во время старта, а на событиях - это ужасно даже для такого эзотерического способа работы с модулями.

[Кирилл]

Кэшируется всегда - без исключений. Посмотрите исходники: https://github.com/nodejs/node/blob/master/lib/mod... Я с вами согласен, что require на событиях это плохо, но не сказал бы, что использование global это хороший совет.

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

Кирилл: да, кешируется не exports а module, согласен. Но вот почему плохо глобал? А то, что setInterval и exports и Math и process и еще куча всего видны глобально, это ничего?

[Кирилл]

Глобальные переменные это анти-паттерн во многих языках, потому что они усложняют отладку и сопровождение кода. При чтении кода не видно кто и как менял эти переменные в других модулях. Есть шанс испортить чужие глобалы случайно.

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

Это просто распространенное мнение про анти-паттерн, а вот почему? Какие такие чужие глобалы, если все глобалы в приложении мои? При хорошем планировании глобальной области видимости, это ни чем не плохо. Библиотеки - да, не должны писать в глобал, чтобы между библиотеками не было конфликтов, чтобы одна не затерла код другой. А вот в конкретном приложении глобалы могут упростить многое, чтобы не писать в 100 местах require, можно добавить, например, fs в глобальный хеш api, тужа же добавить os, domain и т.д. Потом обращаться через api.fs.readFile всегда, в приложении. Ни какого риска нет. Кроме того, зависимости это такая вещь, которую логично объявлять в декларативной форме, вот в package.json они о объявлены, потом взяли и при старте все загрузили и все везде доступно.

[Кирилл]

Если проект ведет один человек, или документация на проект расписана идеально - то можно сказать что глобалы не представляют угрозы. Но на моей практике такие случаи редкость и таких привычек проще и надежнее избегать.

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

Кирилл: я согласен, что есть языки и фреймворки в которых глобалы обязательно приведут к запутыванию кода. Кстати, в js изменение базовых прототипов, как string и Date - это тоже своего рода глобалы, т.е. влияет на весь код и проникает своим действием в библиотеки, которые этого вовсе не ожидали. Но в ноде есть замечательный способ управлять глобалами и вообще контекстами - это встроенная библиотека vm: https://nodejs.org/api/vm.html На самом же деле в ноде нет совсем глобального контекста или, точнее, мы никогда не имеем к нему реального доступа. Все файлы, загруженные через require или vm.Sctipt по сути обернуты замыканием, в которое мы можем передать любой контекст, созданный нами специально через vm.createContext или полученный из других частей приложения. И из скрипта он будет виден как глобал и в нем же можно сделать ссылку на самого себя типа context.global = context чтобы было с ним удобно работать. Таким образом части приложения можно экранировать одну от другого так, как мы этого захотим. Я вот почти всегда делаю минимум два слоя в приложении: системный и прикладной. У каждого свой глобал, чтобы приложение могло использовать свой глобальный контекст и делать в нем, например прикладной кеш, необходимый для конкретной задачи предметной области, не универсальный. А системный слой имеет свой кеш, что там сожет быть связано с HTTP или TCP протоколом, например, и так они не конфликтуют. Более того, отдельные эти песочницы (псевдо-глобальные контексты) можно разрушать и создавать заново, их можно даже персистать в базу данных при рестарте возвращая состояние приложения, да что угодно можно делать, очень гибкий инструмент. Рекомендую!