Что делать если проект разрастается до 4-6 приложений?

Question

[antimodern]

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

Но вот уже мой проект разросся до 4 отдельных приложений: фронтенд, отдельное апи для фронтенда, фронт админки CMS, и сам апи CMS. В планах еще отдельный сервис самодельной аналитики и вебсокет сервер.

Я молчу и не спрашиваю про деплой этого зоопарка (пока обхожусь баш скриптами).
Но меня напрягает даже локально каждый день запускать ручками 4 приложения чисто для разработки)

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

Comments

[longclaps]

Начинай уже праздновать!
До четырёх! Разросся! Это реально круто!

Answer 1

[Saboteur]

Но меня напрягает даже локально каждый день запускать ручками 4 приложения чисто для разработки)

Плохие баш-скриптики. Можно же написать один, который за вас все запустит.

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

Можете еще и в докер попробовать.

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

Comments

[sim3x]

+systemd для каждого сервиса

[antimodern]

Плохие баш-скриптики. Можно же написать один, который за вас все запустит

Я ж писал про скрипты для деплоя :)

А как мне баш скрипт поможет запустить 4 приложения? По каждому вдь мне нужен отдельный вывод в консоль. Как все настраивать в таком случае?

[antimodern]

sim3x, зачем systemd? Это про деплой? Там pm2

[sim3x]

antimodern, стандартное средство поднятия демонов

[Saboteur]

antimodern, А зачем вам отдельный вывод в консоль?
Почему бы не делать вывод сразу в лог-файл? А в этом случае все просто

./app1 >> app1.log &
./app2 >> app2.log &

[antimodern]

Saboteur, зачем мне лог файл при разработке? Для самого элементарного тестирования.

[Saboteur]

На самом деле, нет никакой проблемы смотреть логи из файла через tail -f.
Даже удобно что всегда с логом можно сделать всякие штуки типа grep. Можно даже добавить в скрипт удаление предыдущего лога.

Можно конечно все приложения в одну консоль и все видеть.
Можно сделать четыре консоли в screen или tmux
Докер сам по себе сделает индивидуальную консоль для каждого контейнера
Можно переписать и хранить логи в базе данных

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

Конкретно вот это, что вы смотрите логи в консоли - мешает вам выбрать множество вариантов автоматизации запуска четырех приложений.
Потому что любая автоматизация подразумевает, что живой консоли не будет. Она будет перехватываться в файл/базу/вникуда.
Бэкенд, например, вообще должен писаться как daemon, то есть изначально предполагать, что он всегда будет запускаться в фоне, без консоли.

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

[antimodern]

Saboteur, спасибо за направление, буду рассматривать такой вариант

Answer 2

[Кирилл Кудрявцев]

Запихнуть все в Docker контейнеры и поднимать с помощью Docker Compose.

Comments

[antimodern]

Я как-то пробовал Докер, оказалось очень неудобно разрабатывать в Докере. Например, непонятно как перезапускать апи сервер во время разработки (nodemon не рекомендуется использовать с Докер и он не корректно работает). И таких мелочей оказалось неимоверно много, и все они пожирают время. В итоге с Докером болше геморроя чем пользы (про деплой я не говорю, возможно деплой с ним проще)

[Alex]

antimodern, я для локалки не "пихаю" файлы в контейнер, а прокидываю папку. Нода запущена через ноде-мун и все рестартует при изменении файла.
Вариант с докером вполне рабочий. Лучший ли, это уже для кого как.