mam для разработки бекенда

[PavelZubkov]

Problem

Пока несколько кейсов встретил, решил в все в одном ишью завести.

1. Сборка не нужных файлов. Сейчас запуск yarn start path/to занимает у меня 45 - 60 секунд. Причем нужные файлы: node.deps.js node.js node.test.js собираются за 0.425 + 3.555 + 5.502 = 9.482 секунды

2. Автоперезапуск. Сейчас цикл выглдяит так: правлю код -> руками запускаю сборку -> руками запускаю бандл.

3. Если в бандле есть запуск долгоживущих процессов, типа http.server.listen(), то надо в тестах шаманить с process.exit(0)

4. Добавление используемых пакетов в сгенерированный package.json. Я добавил в mam_lib пока локально, пакет pg для постргесс. Руками установил его в mam. В сгенерированном package.json его нет

5. Не хватает неймспейсов для переопределения класса для бекенда в node.ts, $ и $$ занят фронтовским компонентом =)

Solution

1. В теории можно ускорить сборку, если будет возможность сказать сборщику собирай мне только нодовский бандл. Например добавить параметр типа 'target=node|all'. Еще можно посмотреть в сторону, что если у пакета есть node.ts файлы, и нету web.ts и просто .ts то собирать только нодовский бандл.

2. Тут не такая большая проблема, я могу сам подключить nodemon и запускать как-то так: `nodemon "yarn start path/to" && "node path/to/-/node.js". Вообще было бы удобно что бы дев сервер, мог запускать нодовские сервера.

Например у меня сейчас в проекте два сервера:
Сам проект - поднимается http сервер и все полученные запросы пишет в базу. Фронт позволяет смотреть какие запросы и когда пришли

• sync - работает с бд и сокетами. Я переписал $hyoo_sync без origin'ов на mam(я понял что нет смысла его пилить сейчас, но просто хотел попробывать))
• server - юзает общую модель с фронтом, слушает http и через $mol_store_shared сохраняет запросы
  и фронт

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

В теории весь запуск дев серверов можно прописать в докере, но как понимаю это удобно только линукс пользователям на винде с докером не так удобно.

3. Тут наверно надо самому делать не безусловный запуск долгоживущих процессов, а по какому-нибудь параметру из командной строки.

4. Было бы удобно не тащить дополнительный package.json с нужными зависимостями из npm. А что бы они добавлялись в генерированный package.json

5. Хотел сервер, который сохраняет http запросы запилить в корневом .ts файле. Например у меня проект лежит в aspirity/restmock, есть файлы:

   • restmock.view.tree - генерирует view.tree.ts который добавляет в неймспейс $ класс $aspirity_restmock
   • restmock.view.ts - руками создаю класс с таким же именем, только через неймспейс $$ переопределяю сгенерированный
   • restmock.node.ts - тут хотел запилить сервер и его запуск, но все неймспейсы для переопределения класса $aspirity_restmock уже заняты.
     Вообще, не большая проблема, могу другое имя использовать

Как итог

Нужно добавлять какие-то дополнительные инструкции в meta.tree (сборка требуемых бандлов , добавление зависимостей в package.json , запуск дополнительных серверов)
и/или придумывать соглашения

[PavelZubkov]

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

1. Сборка не нужных файлов. Сейчас запуск yarn start path/to занимает у меня 45 - 60 секунд. Причем нужные файлы: node.deps.js node.js node.test.js собираются за 0.425 + 3.555 + 5.502 = 9.482 секунды

В ручных подсчетах еще несколько файлов не учел, сделал сборку только нодовских файлов, получилось 25 - 30 секунд

позже попробую автоперезапуск со слежением прикрутить

[nin-jin]

1. По идее эта проблема должна решиться, когда сделаем автосборку нодового бандла.

2. Там надо пошаманить с тест-раннером ($mol_test), чтобы он автоматически дёргал precess.exit(0) в конце тестов. По идее это не сложно.

3. Если использовать $node.pg, то должен автоматом в package.json попадать.

4. Сервер и клиент - это всё же разные приложения, которые должны находиться в разных директориях. Возможность разделения кода на клиентский/серверный нужна для предоставления единого интерфейса, но с принципиально разными реализациями.

[nin-jin]

3. Поправил, теперь тестовый бандл всегда завершается.

[nin-jin]

Есть идя как сделать автосборку сервера. Девсервер слуiает запросы вида /my/server, собирает и запускает серверный бандл и перенаправляет этот запрос к нему. В случае изменения файлов сервер глушится и при следующем запросе пересобирается и перезагружается заново.

[PavelZubkov]

Если я правильно понял: такое не будет работать если фронт с сервером по сокетам общаются?

[nin-jin]

Почему же, вполне будет. Сокет соединение разорвётся, клиент попытается переконнектится и поднимет сервер.