Сервер из нескольких nodejs-процессов вместо одного. Есть ли смысл?

Не вижу ничего плохого. Зависит от задачи, но, лучше, наверное, через Redis, чем через HTTP.

Из плюсов: удобно масштабировать какое-то одно место, удобней разрабатывать, распределить задачи между разработчиками, удобней поддерживать.

Лучше взять какой-нибудь Erlang.

У меня такие же мысли на этот счет. Просто ни разу не слышал чтобы кто-то делал так на node )

Erlang не понравился. Рекурсия там, неизменяемые переменные. Думал скалу под это дело освоить, но понял что не осилю )

неизменяемые переменные

твоя безнадёжность делает анонимуса грустным с самого утра

удобно масштабировать какое-то одно место

Это сраная пачка датчиков, чего там масштабировать?

удобней разрабатывать

На каждый чих api в транспорт оборачивать? Ню-ню.

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

Чушь. Модули они и в африке модули, независимо как их дергать.

ТС, если хочется поинженерить, то делай отдельные express-приложения на каждый сервис и собирай их под одним процессом. Если понадобится разнести, всегда сможешь сделать.

На каждый чих api в транспорт оборачивать? Ню-ню.

А как еще сделать абсолютно несвязные модули, если только не через обмен сообщениями

А как еще сделать абсолютно несвязные модули, если только не через обмен сообщениями

О, мы где то прочитали что связанность это плохо? М-м-м, понимаю. Не буду мешать в таком случае. Приобретение опыта — ценнейшая вещь.

Стратегически все правильно, так твоя управлялка становится совершенно неуничтожимой :)

golang который уже есть.

либо (Nodejs +csp) которые к друг другу прикручивать самому придётся ( т.е нода из за однопроцессности может выполнять только задачи одного актора(очень жирного и внутри себя ....) - межакторное взаимодействие тебе придётся тем или иным палиативом осуществять)

абсолютно несвязанные модули не взаимодействуют, ни напрямую, ни опосредованно.

ты словом «абсолютно» ввёлся в заблуждение.

не понравился... неизменяемые переменные.

Ну, повзрослеешь - поймёшь. Правда, будет поздно.

Неизменяемые переменные хороши в узко ограниченном круге задач. Не комильфо ради этого целый язык изучать )

Держи прототип программы на нормальном языке с concurrency.

func main() {
    go relays.RelayLoop()
    go aircond.CondLoop()
    go scenes.ScenesLoop()
    go events.EventLoop()
    http.ListenAndServe(":8080", nil)
}

Динамически типизированный говноязычок JavaScript в управляющей системе - это просто песец. Если хочешь модных технологий, то уж лучше Go.

Что будет с остальными горутинами, если где-то в недрах RelayLoop отвалится TCP-соединение и он выдаст ошибку? Я не язвлю. Правда не знаю. Го перезапускает поломанные процессы?

Отвалившийся node-процесс я могу перезапускать до посинения systemd-правилом )

Дык это прописные истины, что он динамически типизированный говноязычок. Кто же спорит) Typescript отчасти спасает.

С го не хочу связываться, потомучто на подходе Rust. Го, по сравнению с ним выглядит лишь немножко менее игрушечным чем руби. Набор конструкций и парадигм ограничен, управления памятью нет, dll-ку из него не создашь. Очень напоминает динамический язычок. ватит с меня динамических язычков )

С го не хочу связываться, потомучто на подходе Rust.

Тут вопрос простой - тебе jff или для работы. Если для работы, то Go, потому что статическая типизация. Если jff, то почему бы сразу на Rust не писать?

В го это ручками делается, например в самой горутине цикл, пересоздающий сокет в случае чего. А так если одна горутина отвалится, а остальные от неё не зависят (не читают из каналов этой горутины), ничего страшного не произойдёт.

В rust же тоже статическая типизация.

Как я уже сказал, повзрослеешь - поймёшь.

Усы - не признак взрослого человека )

- Мне надо повесить картину. Какой молоток лучше взять, что бы дырки сделать?
- Возьми перфоратор.
- Он жужжит! Лучше молотком. Так какой молоток лучше для этих целей?
- Возьми перфоратор.
- Перфоратор жрёт электричество, молотком лучше! Так что на счёт молотка? Каким лучше сверлить стены? Что подскажут анонимусы лора?
- Возьми перфоратор.
- Усы - не признак взрослого человека!

Та нормалёк. Можно и так.

У мну несколько иначе, но пока на бумажке - жду железячку из Китая.

Ну лень мне перфоратор осваивать. Потомучто, во-первых, на фасадных работах (фронтэнде) только молотком можно. Во-вторых, лучше я попозже освою Универсальную-Турбо-Др***лку (rust), а пока напишу на том, что знаю). В третьих, в перфораторе вместо мотора - магический хвостатый зверек, вызывающий сам себя, и написанная фюррером инструкция, почти полностью состоящая из запретов. Это нельзя, то нельзя.

Не комильфо ради этого целый язык изучать

Поспорил бы, ну да ладно.

а чего ж не RUST?

Tnx, повеселил.

твоя управлялка становится совершенно неуничтожимой :)

И это прекрасно =))

У меня посложнее. С внешним контуром пока не знаю как поступить.

а чего ж не RUST?

Rust не стабилен даже как язык (в списке рассылки иногда такое обсуждают...) и не существует как платформа. Делать на нем что-то для работы я бы не стал и никому не посоветовал бы.

P.S. ты бы еще R.U.S.T. написал, блин.

Может расскажешь концепцию? Может интересные идеи появятся)

Да какая разница, пиши на чем знаешь да и все - для себя же. Там в процессе будет видно. Тут вон люди свой аналог автокада на паскале пишут, а создай такой тред «пишу автокад на паскале, нормально ли?», что «насоветуют»? Про взаимодействие, я ни в чем не разбираюсь, но: слышал про ZeroMQ?

Один нод процесс грузит один процессор. Если у тебя 4 ядра, то 1 процесс загрузит максимум одно. Поэтому несколько процессов нужны, если ты делаешь нагруженный сервис.

В твоём случае никакого смысла усложнять себе жизнь нет. Делай всё в одном процессе.

Я и пишу на чем хочу. Тут народ просто начал предлагать кто во что горазд, вот и приходится оправдываться )

Про ZeroMQ спасибо что напомнил. Видать, пришло время его раскурить. Redis pub/sub хорош, но он умеет только публиковать. Лень дописывать поверх RPC. Может в 0mq уже есть готовое)

Ну для человека решающего такую задачу на nodejs почему бы и нет?

P.S. а ^R^.^U^.^S^,^T^ написать можно?

Я наоборот думаю как упростить себе жизнь. Предыдущая версия управлялки, написанная в виде классов и связанных модулей быстро разраслась и вышла из под контроля. Хочется разбиения на маленькие независимые кусочки. Вопрос в том, какие могут быть подводные камни во взаиможействии нескольких node-процессов

Еще раз повторюсь, сам не использовал, но там есть много чего в т.ч. и pub/sub. Техническую документацию известно где найти, а вот для чтения на досуге:

http://rus-linux.net/MyLDP/BOOKS/Architecture-Open-Source-Applications/Vol-2/...

удобно масштабировать какое-то одно место

В умном доме? Может еще Hadoop, Cassandra, Kafka?

С го не хочу связываться, потомучто на подходе Rust

Го конечно не настолько торт, как Rust. Вот только вот это «на подходе» уже долго, не смотря на активность в гитхабе

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

А если «ненативная либа» упадет? Какие-нибудь огрехи в логике и, например, при некотором стечении обстоятельств, программа, попробует обратиться к полю объекта, который в этот момент равен null и вывалится с ошибкой..

Не, такого никто в управляемых языках не боится. Стоит какой-то try-catch, ловит сообщение, пишет в лог и потом следующие eventы. Фиксится на уровне бизнеслогики. Это натив доставляет

Искусственно усложняя себе жизнь ты её не упростишь. Писать слабосвязные компоненты можно, и гораздо проще, внутри одного процесса.

А зачем тебе разные инстансы node? Делай все в одном экземпляре - управляемые процессы все медленные, никакого хайлоад или даже зачатков для необходимости что-то масштабировать там нет, будет у тебя удобный централизованный лог, нет гемора с MQ (а если уж хочется mq, можешь присмотреться к github.com/visionmedia/axon). Вешаешь его на forever и живешь в своем умном доме.

С го не хочу связываться, потомучто на подходе Rust.

Rust — не нужен, ибо есть хаскель. А вот го, как C done right и с батарейками, весьма и весьма любопытен.

PS: Все кошусь на галиосовский Ivory, но пока негде опробовать.

Расскажу попозже, занят пока.

Я тут народу обещал выложить историю успеха.

В третьих, в перфораторе вместо мотора - магический хвостатый зверек, вызывающий сам себя, и написанная фюррером инструкция, почти полностью состоящая из запретов.

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

И при этом учти, что я пишу на спп, а перфоратор использовал всего пару раз в жизни. Один раз написал слегка упоротый у-комбинатор, а второй - использовал самописный сервак для тестирования своего спп говнокода для передачи данных по tcp/ip. Такие дела.

с одной стороны это правильно, разделение труда своего рода, с другой стороны лишний геморой )

ну и поменьше советчиков слушай, ерланг, го, лисп, скала, ребята просто не в курсе что от этого лучше твой умный дом не станет :) нода задачу тут выполнит идеально.

P.S. по сути несколько инстансов имеет смысл вешать если у тебя будут несколько серверов, а так упадет один, упадет все - какая разница? я не думаю, что ты собрался строить датацентр для управления умным домом. вобщем смысла нет делить.

Спасибо за axon. Req/rep, да еще и с автоматическим реконнектом - какраз то, что нужно )

Rust — не нужен, ибо есть хаскель. А вот го, как C done right и с батарейками, весьма и весьма любопытен.

Не С, а С++. И Rust и Go - C++ done right и с батарейками