Вот, да, хороший вопрос. Кто как организовывает структуру проекта, какие есть best practices?
отдельные сервисы живущие в разных репах
Anton
Vladimir
Vladimir
Полторы тысячи строк - это несерьезно
Vladimir
Можно и в одном файле держать
Andrew
пока полторы. Но это начало. И судя по ТЗ будет до 5
что там такого эдакого в чат-сервере наверчено, что 5 тыщ строк будет?
Nikolay
В одном файле это, конечно, перебор.
Vladimir
Разбивать на репы нужно только в крайнем случае
Vl
Там много чего будет. И видео чат. Со стримингом видео на все платформы по разным протоколам.
Vl
и еще куча плюх
Andrew
Там много чего будет. И видео чат. Со стримингом видео на все платформы по разным протоколам.
бей на логические блоки, выноси их в отдельные файлы, подключай в центральном агрегаторе
Andrew
собираться все будет один раз, при старте сервера, в процессе работы будет выглядеть как один файл, а работать удобнее
Andrew
имхо
Andrew
а в целом звучит как несколько специализированных серверов, которым даже в одном месте быть не обязательно
Andrew
подумай над тем, что если вдруг эта штука взлетит, то придется масштабировать
Andrew
все равно будешь части потом выносить на отдельные потоки или даже машины
Nikolay
а в целом звучит как несколько специализированных серверов, которым даже в одном месте быть не обязательно
Тогда микросервисы, редис какой-нить, и вперед :)
Vl
Я знаю. Над масштабированем думали. Но сказали, что думать о нем не надо. А в целом пишется так что если добавить еще один сервер то оно расширился нормально.
Ohar
пока полторы. Но это начало. И судя по ТЗ будет до 5
Это ни о чём. У меня некоторые легаси-контролеры большего размера (руки не доходят переписать).
Будет тысяч 20 строк в проекте - можно будет задуматься о разделении.
Igor
Это ни о чём. У меня некоторые легаси-контролеры большего размера (руки не доходят переписать).
Будет тысяч 20 строк в проекте - можно будет задуматься о разделении.
Тоесть лучше подождать пока появяться контроллеры на 1000+ строк
Igor
и тогда только задуматься о разделении
Ohar
Нет, конечно
Ohar
Контролеров на 1000 строк не нужно допускать
Ohar
Но париться насчёт разделения сейчас пахнет матёрой такой преждевременной оптимизацией
Igor
Но париться насчёт разделения сейчас пахнет матёрой такой преждевременной оптимизацией
А я вижу это как регулярный рефакторинг
Igor
Помоему выстраивание правильной структуры проекта должно входить в каждодневную привычку, а не быть чем то вроде снега на голову. Хотя конечно забегать далеко вперед не стоит.
Yergali
всем привет
Yergali
пишу небольшой чат
Yergali
работаю с монгуз
Yergali
ошибки вызодят
Yergali
DeprecationWarning: Mongoose: mpromise (mongoose's default promise library) is deprecated
Таймураз
Добавь bluebird в проект
yarastqt [msk +1 week]
mongoose.Promise = Promise;
yarastqt [msk +1 week]
нативные промисы
yarastqt [msk +1 week]
либо блубирд
Таймураз
global.Promise = require('bluebird');
yarastqt [msk +1 week]
можно и нативными обойтись
Таймураз
Ну и для монгуса самого, да
Таймураз
Эти побыстрее будут
Yergali
спасибо
yarastqt [msk +1 week]
Мне кажется если не особо много запросов будет, то блюбирд и нативные промисы ничем не отличаются
Таймураз
Да какая разница
Всего лишь одна зависимость и 2-3 строчки сверху
Yergali
пару слов о себе: я java программист постепенно осваиваю node.js
yarastqt [msk +1 week]
:D
yarastqt [msk +1 week]
Vladimir
0 зависимостей лучше чем одна
Vladimir
И пора запомнить, что подменять глобалы нехорошо
Дима
Да да да, а весь проект в одном файле лучше чем модульный подход
Дима
Это не подмена глобалов
Vladimir
Это именно что подмена глобалов
Vladimir
global.Array = require('хуита');
Дима
Пфф
Vladimir
безумие
Дима
Никто не мешает объявлять как BluebirdPromise
Дима
Это первое
Дима
Второе, это НЕ глобал
Vladimir
Это ради бога
Таймураз
Господи, стороннее решение оказалось лучше, чем нативщина, а вы против?
Дима
А, сорян
Таймураз
Почему?
Дима
Я извиняюсь)) Не присмотрелся к выложенному синтаксису
Дима
Да, так делать не стоит
Vladimir
Если бы они были полностью идентичны, но производительнее, это была бы другая история
Дима
Если бы они были полностью идентичны, но производительнее, это была бы другая история
Ну отмена промисов например по умолчанию выключена
Таймураз
Так у блуберда же только несколько методов лишних поверх спеки
Vladimir
Это уже красный флаг
Дима
Оок
Vladimir
Наличие лишних методов - красный флаг
Vladimir
Появляется неявная зависимость
Таймураз
Если реализация отличается, то ок
А вот с лишними методами не могу придумать случая, когда что-то сломается
Ale
а где именно?
Vladimir
Сломается, когда в нативные промисы добавят метод с таким же названием
Vladimir
Проходили уже и не раз
Vladimir
И спеку меняли из за таких умников
Ale
Array includes ((
Таймураз
Сломается, когда в нативные промисы добавят метод с таким же названием
Уже были случаи, когда нативные промисы так меняли?