batuev_evgeniy: отчего же? Совсем нет, у меня например была как-то курсовая по системотехнике на тему контроля качества изделий.
Еще как вариант, коль уж мы привязались к станкам - выполнение копий изделий, или еще чего такого. Почитайте чего про нейроуправление, может каких идей найдете.
vasIvas: ну начнем с того что я монгу если и использую то не в коем случае не как основное хранилище (уже наступил как-то на эти грабли, больше не хочу). В общем и целом у меня на сервере всегда есть REST Api, а на node.js я пишу только штуки где нужно работать с I/O (обработчики задачи из очередей, пуш-сервера и т.д.).
Далее, мангус реализует паттерн Active Record, который меня бесит, да и он только под один бэкэнд затчен. js-data же реализует data mapper, который меня радует. Вот и все.
vsuhachev: ну добрая половина уже есть. Что до строгой типизации... вы когда-нибудь работали над реально большим проектом? TS дает вам огромное преимущество в виде статического анализа кода и поиска багов до того, как вы вообще код куда-то выкатили. Преимущество это не столь существенно ровно до тех пор, пока не спасет хоть раз. Ну и опять же, автокомплит работает просто восхитительно.
nepster09: общение между компонентами систем делают обычно через очередь сообщений. Ну мол один сервис запихнул в очередь "сделай мне эту хрень" а какой-то воркер подобрал, сделал и через pub/sub они обменялись результатами. Это позволяет добиться большей производительности системы и большей гибкости, так как мы не зависим от конкретного воркера. В случае с rest мы должны знать кто будет делать дела, а в случае с MQ нам без разницы, лишь бы сделали. Ну и прослоек меньше.
nepster09: вы поймите, REST для взаимодействия между бэкэндами крайне не эффективен, если сравнивать со штуками типа MQ через какой RabbitMQ или кафку, которые сами разруливают маршрутизацию сообщений и т.д. Это позволяет добиться изоляции отдельных сервисов и сегрегировать ответственность. А то что вы предлагаете сделать, это как бы так же вариант, использовать HTTP как интерфейс к приложению, но это чуть более чем странно, учитывая что можно построить взаимодействие ежду UI-layer и Application layer по старинке.
nepster09: ну как вам сказать, этот подход практикуют, только используют вещи поэффективнее (MQ), а REST API должно быть так же в таком случае отдельным приложением использующим основное через MQ.
вообще вы не должны покрывать контроллеры юнит тестами (если у вас там есть какая-то логика, то это уже идеологически не верно), только E2E. А вся логика должна быть вынесена либо в директивы либо в сервисы. Контроллеры это просто медиатор между UI и логикой.
nepster09: короче основная мысль в том, что контроллеры становятся тонкими, их задача перевести из формата представления (REST, HTTP, RPC, MQ или еще чего) в единый формат приложения, DTO, имутабельный объект который нужен для переправки данных между слоями. Тогда нет никаких проблем с тем что бы сделать одновременно и WEB и REST и что угодно.
