Как поднять монорепо с пятью сервисами и не потеряться в портах

Стою перед проектом Notes Server — это не просто API, а полноценное расселение из пяти соседей: бэкенда на Node.js, веб-клиента на Vue, сервиса эмбеддингов, CLI-клиента и Telegram-бота. Всё упаковано в монорепо с workspaces, и каждому нужна своя забота.

Первый вопрос, который приходит в голову: как всё это запустить, чтобы работало одновременно? Оказывается, не так уж сложно, если знать порядок операций.

Начинаю с npm install в корне. Когда используешь workspaces, эта команда автоматически разворачивает зависимости всех пакетов — от packages/server до packages/embeddings-service. Это экономит кучу времени: один раз — и готово.

Дальше запускаю сервер на портe 3000. Он натирает API-маршруты: /api/notes, /api-docs с документацией Swagger. Одновременно поднимаю веб-клиент на Vite — он работает на портe 5173. И вот тут начинается магия: в vite.config.ts настроен прокси, который автоматически перенаправляет все запросы к /api на http://localhost:3000. CORS не мучает, всё гладко.

Потом проверяю: а хоть работает ли бэкенд? Делаю запрос на /api/notes — и получаю ошибку 404 Not Found. Первая мысль: маршруты не зарегистрированы. Лезу в notes-routes.ts, смотрю на структуру приложения. Оказывается, в index.ts после инициализации приложения добавляются статические файлы и catch-all маршрут /. Порядок регистрации маршрутов критичен в Express — если поймёшь это слишком поздно, потратишь час на отладку.

Вот такая вот история получается: казалось бы, стандартный монорепо, но каждый компонент требует внимания. Vue знает, куда стучать, сервер знает, где слушать, а Telegram-бот ждёт своего часа где-нибудь на боку.

Интересный факт: в экосистеме Node.js монорепо с npm workspaces — это не просто удобство, это стандарт. Prometheus, самый популярный инструмент мониторинга, тоже использует что-то подобное в своей архитектуре… ну, почти. Потому что Prometheus считает, что он лучше всех, и вообще Stack Overflow так сказал 😄