Нет

RTFM

Вопрос века

?

Вопрос. Допустим у меня есть чат-сервер на nodejs. Там очень много всего. И он уже обрастает кучей кода. Функционала там не меньше. И так вышло, хоть я т выносил модели db в разные файлы. Старался писать код покороче. Все равно его уже очень дохера. Кто знает как грамотно можно реструктуризировать приложение, пока еще не поздно и есть время. Ибо потом может быть совсем тяжко

сколько тысяч строк кода?

Разбивай на маленькие модули по функциональности. Каждый модуль клади в отдельный репозиторий.

Вот, да, хороший вопрос. Кто как организовывает структуру проекта, какие есть best practices?

сколько тысяч строк кода?

пока полторы. Но это начало. И судя по ТЗ будет до 5

Вот, да, хороший вопрос. Кто как организовывает структуру проекта, какие есть best practices?

отдельные сервисы живущие в разных репах

Разбивай на маленькие модули по функциональности. Каждый модуль клади в отдельный репозиторий.

Не надо так делать

Полторы тысячи строк - это несерьезно

Можно и в одном файле держать

пока полторы. Но это начало. И судя по ТЗ будет до 5

что там такого эдакого в чат-сервере наверчено, что 5 тыщ строк будет?

Полторы тысячи строк - это несерьезно

Тогда действительно не надо.

В одном файле это, конечно, перебор.

Разбивать на репы нужно только в крайнем случае

Там много чего будет. И видео чат. Со стримингом видео на все платформы по разным протоколам.

и еще куча плюх

что там такого эдакого в чат-сервере наверчено, что 5 тыщ строк будет?

Ответил выше

Там много чего будет. И видео чат. Со стримингом видео на все платформы по разным протоколам.

бей на логические блоки, выноси их в отдельные файлы, подключай в центральном агрегаторе

собираться все будет один раз, при старте сервера, в процессе работы будет выглядеть как один файл, а работать удобнее

имхо

а в целом звучит как несколько специализированных серверов, которым даже в одном месте быть не обязательно

подумай над тем, что если вдруг эта штука взлетит, то придется масштабировать

все равно будешь части потом выносить на отдельные потоки или даже машины

а в целом звучит как несколько специализированных серверов, которым даже в одном месте быть не обязательно

Тогда микросервисы, редис какой-нить, и вперед :)

Я знаю. Над масштабированем думали. Но сказали, что думать о нем не надо. А в целом пишется так что если добавить еще один сервер то оно расширился нормально.

пока полторы. Но это начало. И судя по ТЗ будет до 5

Это ни о чём. У меня некоторые легаси-контролеры большего размера (руки не доходят переписать). Будет тысяч 20 строк в проекте - можно будет задуматься о разделении.

Это ни о чём. У меня некоторые легаси-контролеры большего размера (руки не доходят переписать). Будет тысяч 20 строк в проекте - можно будет задуматься о разделении.

Тоесть лучше подождать пока появяться контроллеры на 1000+ строк

и тогда только задуматься о разделении

Нет, конечно

Контролеров на 1000 строк не нужно допускать

Но париться насчёт разделения сейчас пахнет матёрой такой преждевременной оптимизацией

Но париться насчёт разделения сейчас пахнет матёрой такой преждевременной оптимизацией

А я вижу это как регулярный рефакторинг

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

всем привет

пишу небольшой чат

работаю с монгуз

ошибки вызодят

DeprecationWarning: Mongoose: mpromise (mongoose's default promise library) is deprecated

Добавь bluebird в проект

mongoose.Promise = Promise;

нативные промисы

либо блубирд

global.Promise = require('bluebird');

можно и нативными обойтись

Ну и для монгуса самого, да

Эти побыстрее будут

спасибо

Мне кажется если не особо много запросов будет, то блюбирд и нативные промисы ничем не отличаются

Да какая разница Всего лишь одна зависимость и 2-3 строчки сверху

пару слов о себе: я java программист постепенно осваиваю node.js

:D

ладно, ладно(

0 зависимостей лучше чем одна

И пора запомнить, что подменять глобалы нехорошо

Да да да, а весь проект в одном файле лучше чем модульный подход

Это не подмена глобалов

0 зависимостей лучше чем одна

+1

Это именно что подмена глобалов

ERROR: S client not available

global.Array = require('хуита');

Пфф

безумие

Никто не мешает объявлять как BluebirdPromise

Это первое

Второе, это НЕ глобал

Это ради бога

global.Promise = require('bluebird');

не надо так делать

Господи, стороннее решение оказалось лучше, чем нативщина, а вы против?

А, сорян

Почему?

Я извиняюсь)) Не присмотрелся к выложенному синтаксису

Да, так делать не стоит

Если ты хочешь использовать bluebird и звать его Promise — делай const Promise = require('bluebird'); наверху каждого файла.

Если бы они были полностью идентичны, но производительнее, это была бы другая история

Это затронет только твои вызовы к Promise.

Если бы они были полностью идентичны, но производительнее, это была бы другая история

Ну отмена промисов например по умолчанию выключена

А если ты подменишь global.Promise, какая-нибудь зависимость может от этого слегка удивиться.

Так у блуберда же только несколько методов лишних поверх спеки

Это уже красный флаг

Хуже только подменять глобалы в либах, это вообще полная задница.

Это уже красный флаг

Выключенная фича — это красный флаг?

Оок

Так у блуберда же только несколько методов лишних поверх спеки

Не только, реализация отличается кое-где.

Наличие лишних методов - красный флаг

Появляется неявная зависимость

И нет, я могу представить себе ситуацию, когда либа сломается от замены Promise.

Если реализация отличается, то ок А вот с лишними методами не могу придумать случая, когда что-то сломается

Не только, реализация отличается кое-где.

а где именно?

Сломается, когда в нативные промисы добавят метод с таким же названием