Итак. 9 октября мы проводим Node.js Meetup 8, в R&D лабе DataArt (м. Выборгская). https://eventuer.timepad.ru/event/892210/  

Если вы хотите выступить с докладом - прошу ко мне в личку.
З.Ы. пока докладчиков 0.

встреча может быть и без докладов, но с докладами веселей)

qq у вас тут не особо активно ) на митапах также ?

Мир да благодать

все в солнечном, погода-то не резиновая

nodejs разработчики не общаются словами. мы обмениваемся чувствами.

Услышал, что хранить Frontend и Backend в одном репозитории “плохо”. Кто-нибудь может пояснить?
Вижу проблему в том, что сделать независимые CI билды будет трудно - при изменении фронтового кода билдить/тестить только фронт.
Из плюсов монорепы:
- атомарные коммиты (фронт+бэк) и централизованная история изменений
- легче добавлять новые фичи / делать сквозные изменения если вы можете и во фронт и в бэк
- все лежит в одном месте, удобно

Понятно, что все зависит от конкретного кейса, команды и компании, но все равно хотелось бы услышать ваши “за” и “против”?

Монорепа требует тулзов вокруг себя. На рынке нет нормальных готовых решений, всем приходится пилить свои

CI вполне нормально может отдельно собирать/тестить фронт и бэк. Для каждого из них свои билд степы, одни смотрят изменения в папке с фронтом, другие в папке с бэком (или все, кроме фронта, если он внутри проекта лежит)

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

BFF мы храним вместе с фронтом — они сильно связаны. А бэки отдельно, так как связь низкая и релизный цикл разный.

Думал больше мнений будет, но все равно всем спасибо! 🙂

Хочется как-то подэтожить:

Ключевые факторы - команда и релизный цикл

Начинать удобней с монорепы
И если команда одна (фулстеки?) - оставаться на монорепе
Если команды станут разные/независимые - можно поделить репы
Если релизный цикл станет разный - точно делить репы

Помнить про то, что у монореп есть цена - необходимы инструменты, которых готовых может и не быть.

монорепа это скорее не про хранение бэка и фронта в одном репо, а про хранение вообще всего в одном репо

Возможно, но такое в основном используется у IT гигантов. Есть ли название для монорепы на уровне проекта? 🙂

Да нет, кажется такое просто называют компонентой

или сервисом

и потом начинают дробить на микросервисы, bff и т.д. Тут скорее не вопрос хранения кода, а вопрос архитектуры

так что у вас не монорепо, а монолит )

Для начала давай определим что такое монорепа?) Если это просто git репозиторий в который вот так всё сваленно в кучу - это не монорепа, это большая помойка.