Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 16
//лист всех файлов в директорииМожно подключать директории с помощью require-dir. Есть несколько пакетов, которые справляются с этой задачей, например require-dir.
можно сделать и так, мы пока не решили, стоит ли это делать из-за пяти сторочек кода.
В инфрастуктуре ноды/npm очень много пакетов, которые состоят из пяти строчек, но, тем не менее, делают жизнь лучше. Я рекомендую узнавать про такие штуки и пользоваться ими, потому что они перекладывают часть технических проблем на пакеты, позволяя сосредоточиться на значимых вещах.
Лично я не пользуюсь require-dir, и этим подходом вообще. Я предпочитаю создавать файл index.js и вручную в него подключать все субмодули. Снаружи можно просто подключать директорию, в этом случае читается индексный файл. Это позволяет прогонять код через бандлеры CommonJS. Да и явное лучше неявного.
Лично я не пользуюсь require-dir, и этим подходом вообще. Я предпочитаю создавать файл index.js и вручную в него подключать все субмодули. Снаружи можно просто подключать директорию, в этом случае читается индексный файл. Это позволяет прогонять код через бандлеры CommonJS. Да и явное лучше неявного.
А не думали методы (get, post,...) в название функции вынести? Например, pub_get_start(). Насколько я понял, сейчас в каждой функции нужно проверять, как пришел запрос?
Не совсем понятно, ради чего топик-то.
Про то, как при поступлении на вход URL'а проверить, есть ли соответствующий файл и сделать ему require? Так в этом ничего такого.
Про то, что хорошо бы использовать унифицированное api для однотипных задач? Ну так и это очевидно.
В общем, странно как-то.
P.S. А что за HTTP status code такой, 999-й? Имхо, правильнее было бы 501-й выставлять.
Про то, как при поступлении на вход URL'а проверить, есть ли соответствующий файл и сделать ему require? Так в этом ничего такого.
Про то, что хорошо бы использовать унифицированное api для однотипных задач? Ну так и это очевидно.
В общем, странно как-то.
P.S. А что за HTTP status code такой, 999-й? Имхо, правильнее было бы 501-й выставлять.
т.е. на каждый запрос вы проверяете наличие файла, потом загружаете его и выполняете действия в фибере? Вы проводили бенчмарки?
А uppercase STATUS, MESSAGE — это что такое? Дикость в уралах (uppercase) вида en/Start — это тоже нормально видимо? Знаете я бы посоветовал никому не делать как вы. Простите конечно, но такое ощущение что вы никогда не работали с нодой.
А uppercase STATUS, MESSAGE — это что такое? Дикость в уралах (uppercase) вида en/Start — это тоже нормально видимо? Знаете я бы посоветовал никому не делать как вы. Простите конечно, но такое ощущение что вы никогда не работали с нодой.
1. с нодой работаю давно и плотно, и как вы писали в своем посте о ноде это лично мое правило, я никому его не навязываю
2. бенчмарки — нет не проводили, но хочу заметить, что механизм импорта файлов в ноде, достаточно сильно отличается от того же пхп, из-за чего и используется forever -w, чтобы не перегружать сервер каждый раз ручками. Система рабочая и пока проблем в Индонезии, даже на слабых серверах замечено небыло, не смотря на то, что используется в социальной сети и для выдачи статистики.
3. у нас есть определенные корпоративные правила, из которых и следует «uppercase » и «Дикость в уралах». Хорошо это или плохо — вопрос воспитания.
2. бенчмарки — нет не проводили, но хочу заметить, что механизм импорта файлов в ноде, достаточно сильно отличается от того же пхп, из-за чего и используется forever -w, чтобы не перегружать сервер каждый раз ручками. Система рабочая и пока проблем в Индонезии, даже на слабых серверах замечено небыло, не смотря на то, что используется в социальной сети и для выдачи статистики.
3. у нас есть определенные корпоративные правила, из которых и следует «uppercase » и «Дикость в уралах». Хорошо это или плохо — вопрос воспитания.
Это доказывает, насколько Вы плохо знаете node.js и его механику. Зачем проверять и загружать каждый модуль, при каждом запросе? Ответ очевиден, Вы пришли с (PHP/Ruby/Python)!
Вобщем то с Ява и С#. А вы не задумывались, что у меня для этого могла быть причина? Если вам все очевидно, то я надеюсь,
. она вам так же ясно видима.
. она вам так же ясно видима.
Причина была одна, динамически подгружать модули без перезапуска приложения. Но Node.js при require(once) хранит модуль в памяти и последующие вызовы его не имеют смысла. Сбор мусора в V8 не сможет нормально работать при таком подходе, когда Вы динамически изменяете приложение в памяти, из этого последуют страшные утечки памяти при каждом запросе. Помните, что Node.js приложение при каждом запросе не убивает себя и не исполняется сверху вниз, более того оно запускается «1 раз и на всю жизнь»
прошу обратиться к meettya по поводу кеширования require в Ноде, если мне не верите.
Ох. Вы только не обижайтесь, идея здравая, но её качество вам бы подкачать.
не делайте так, процы с гипертрейдингом (или как там называется эта маркетинговая шляпа) наивно отдают х2 ядер, что по факто вранье и толком не работает. Вынесите в конфиг.
Статус 999 — детский сад. Есть rfc на статусы ответов, возьмите подходящий код.
Забудьте про синхронные вызовы. ИМХО их использование нельзя оправдать ничем. Ну разве что эмм. невысоким уровнем разработчика. Очень невысоким.
Забудьте про global. Или реквайрте явно, или передавайте параметром. Глобали вообще нет оправданий, даже если это написал Ризинг. Но он так не сделает.
Именование функций местами сбивает с толку. Не пишут ok, пишут isOk, ибо булен-флаг.
И последнее (на что у меня хватило сил) — реквайр ноды устроен хитро и конечно же кеширует последующие require, но идея делать его на каждый запрос вызывает оторопь.
В общем у вас есть место для улучшений.
var workerCount = require('os').cpus().length;
не делайте так, процы с гипертрейдингом (или как там называется эта маркетинговая шляпа) наивно отдают х2 ядер, что по факто вранье и толком не работает. Вынесите в конфиг.
Статус 999 — детский сад. Есть rfc на статусы ответов, возьмите подходящий код.
Забудьте про синхронные вызовы. ИМХО их использование нельзя оправдать ничем. Ну разве что эмм. невысоким уровнем разработчика. Очень невысоким.
Забудьте про global. Или реквайрте явно, или передавайте параметром. Глобали вообще нет оправданий, даже если это написал Ризинг. Но он так не сделает.
Именование функций местами сбивает с толку. Не пишут ok, пишут isOk, ибо булен-флаг.
И последнее (на что у меня хватило сил) — реквайр ноды устроен хитро и конечно же кеширует последующие require, но идея делать его на каждый запрос вызывает оторопь.
В общем у вас есть место для улучшений.
Спасибо за развернутый коментарий.
«реквайр ноды устроен хитро и конечно же кеширует последующие require, но идея делать его на каждый запрос вызывает оторопь.» — как я уже говорил, я работаю с группой Индонезийцев и они гораздо хуже «обезьяны с гранатой», эта проверка позволила исключить вылет системы и обеспечить стабильную работу даже, если они удалили, переименовали или добавили новый суб-модуль.
синхронный вызов тут только один и он вызывается при старте ноды, по поводу wait.launchFiber, я не нашел возможности сделать это асинхронно.
Не пишут ok, пишут isOk, ибо булен-флаг. — мой косяк
,
global — я храню там глобальный конфиг, с подключениями к базам данных, доступные языки, общие константы. Мой опыт голосует за разумное использование этой возможности.
А вобщем за идею загнать колличество процов в конфиг — спасибо, но есть один нюанс, если Индонезийцы будут переносить систему на другой сервер, то с гарантией 90%, они забудут это изменить. Буду искать реальный способ определить колличество доступных ядер. Хотя пока мне везло с серверами.
«реквайр ноды устроен хитро и конечно же кеширует последующие require, но идея делать его на каждый запрос вызывает оторопь.» — как я уже говорил, я работаю с группой Индонезийцев и они гораздо хуже «обезьяны с гранатой», эта проверка позволила исключить вылет системы и обеспечить стабильную работу даже, если они удалили, переименовали или добавили новый суб-модуль.
синхронный вызов тут только один и он вызывается при старте ноды, по поводу wait.launchFiber, я не нашел возможности сделать это асинхронно.
Не пишут ok, пишут isOk, ибо булен-флаг. — мой косяк
,
global — я храню там глобальный конфиг, с подключениями к базам данных, доступные языки, общие константы. Мой опыт голосует за разумное использование этой возможности.
А вобщем за идею загнать колличество процов в конфиг — спасибо, но есть один нюанс, если Индонезийцы будут переносить систему на другой сервер, то с гарантией 90%, они забудут это изменить. Буду искать реальный способ определить колличество доступных ядер. Хотя пока мне везло с серверами.
Насчет синхронных функций Вы не правы. Почему при загрузке приложения я не могу делать так:
if (fs.existsSync(__events))
fs.readdirSync(__events).forEach(function (eventName) {
if (!jsFileRegexp.test(eventName)) return;
debug('load event', eventName);
require(path.join(__events, eventName));
});
if (fs.existsSync(__events))
fs.readdirSync(__events).forEach(function (eventName) {
if (!jsFileRegexp.test(eventName)) return;
debug('load event', eventName);
require(path.join(__events, eventName));
});
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Построение модульной системы на основе Nodejs