Не ме разбра...
Значи gicho не за сефте мъдри концепции, преди беше нещо за ембедед страната. Това ме кара да мисля, че на ниво CNC или каквито там машинки човъркат нямат стабилен софт и стабилен интерфейс. От страна клиентски софтуер/фронтенд сигурно тепърва го мислят, демек и там мъгла.
Демек предположението ми е, че от една страна свързват машинки с интерфейс/функции дето сигурно ще се променят, от друга страна клиентите ще искат да зяпат/управляват незнайно през какво и как, а по средата облак...
И тъй като съм минал през много подобни ситуации, знам че тоя сорт проблеми не могат да се решат с инструменти. Ако щеш ползвай инструмент от чисто злато пак няма да стане работата. Даже напротив, колкото по-мощен е инструмента толкова вероятността да се забатачат още повече е по-голяма. Не познавам наистина node.js но от интро-то му само ми е достатъчно за да преценя, че в случая той може много яко да ги закопае. Примерно в сравнение с php виждам че тук може да се правят и по-сложни неща. Биха могли директно да свържат устройство с клиент. Наистина възможностите изглеждат повече, но работата е там че НЕ бива да се ползват безразборно. Ако искат да си изчистят концепцията трябва нещата да се разделят, връзките между тях да се опростяват и изолират. Ембедед устройството трябва да си говори само с неговия си посредник. Така ако нещо се счупи, то ще се счупи в тоя участък. Ако нещо трябва да се измени, то трябва да е само в тоя участък. Обратното направиш ли връзка по цялата верига става мазало. Счупи ли нещо може да е навсякъде, ако трябва нещо се промени може да се наложат промени навсякъде. Невъзможно е...
Иначе не съм против джаба, нито против джаба скрипта, нито неговите възможности. Сигурен съм че може да бъде много полезен НО САМО АКО се ползва правилно. Ще дам един пример за подобно хитро използване. В HAVI стандарта се дефинират различни по типове устройства (аудио, видео и т.н.). Може да имаш да кажем телевизор и примерно CNC машина. Производителят на телевизора може изобщо да не е чувал за CNC машини, а CNC пък никога да не си е помислил да се вързва към телевизори. Но удивителното е, че връзката е възможна, включително да зяпаш или да управляваш машината през дистанционното... Въпрос на няколко просто концепцийки, които трябва да се спазват и един световно неизвестен стандарт. Не са необходими кой знае какви софтуери или хардуерно промени. Достатъчно е двете устройства да са в една мрежа, CNC машинката да има един флаш с малко джабарски функции и талавизора да има прозт броузер... Просто и ефикасно, може би заради това не се ползва, щото всеки отива да се закопава в сложнотии...

Е, точно за това им трябва да стъпят на платформа която обхваща всичките им нужди, има перспектива (разбирай голямо комюнити). Инвестирането в ноде се изплаща много добре точно за такива проекти.

Не, точно затова НЕ е необходимо да стъпват на такава платформа
Ако искаш да правиш независими неща, не ти е нужно лепило, пък било то и много качествено...

Е, сам стигна до правилният извод - доколкото разбирам, те не искат да правят независими неща а свързани неща - затова им трябва качествено лепило за свързване

Ще го обясня по друг начин...
Нека за пример вземем WWW технологията. Дали тя щеше да бъде същата ако всеки сайт можеше да се разглежда само с уникален за него софтуер/броузър? Не нали? Щяхме да четем само няколко сайта за които имаме броузъри и до там...
Универсалността, т.е. възможността с един браузър да отваряме който си искаме сайт според мен е в основата на бума на интернет. Тази универсалност общо взето се дължи на едни прости http & html. От друга страна имаме инструменти с много по-големи възможности - JS,флашове, млашове и т.н. Те ни дават много повече възможности да зяпаме шаранийки, анимации и куп други неща дето не са лесни или изобщо възможни с простия html.
Ако трябва да избираш - дилемата е очевАдна. Или се ограничаваш до нещо просто, но което ще бачка навсякъде. Или избираш нещо с много възможности, но на цената че няма да се поддържа баш навсякъде.

В случая става дума за други неща, но идеята е същата. Ако Гичо знае точно с какви машинки ще си има работа и точно с какви софтуери в облаците и след облаците - ОК, съгласен съм че трябва да избере възможно най-мощният инструмент дето ще му свърши точно тая работа...
Но аз не съм убеден че Гичо знае какво има или ще има утре от двете страни. И най-вероятно ще има много изненади, тъй че на негово място бих мислил за универсалност, а не мощност

Първо, ако правя "концепция" която е зависима (като цяло) от това какво ще има утре от някоя страна (външната, другото ние го правим) по-добре да не се хващам?
Второ, ако ми посочиш по-универсален инструмент на драго сърце ще го разгледам и проуча.

Умишлено говоря за "наши устройства", за облаци и за клиенти - точно защото идеята е да се развиват независимо, разкуплирано, по-точно да не налагат ограничения един на друг. "Концепцията" е един отбор (вътрешен) да прави реализациите в нашия ембедед софтуер, по всяка вероятност там js няма да има. Друг отбор, може би пак наш, или външно консултиран, базиран на някаква технология ще прави "централната" точка - сървър, облак, gateway, името не е от значение. Трети тип отбори ще правя фронтенд-а - за вътрешни цели ще сме ние - най-малкото за тестване и добиване на опит, за демонстрации, за "бедни" клиенти, но целта е да предлагаме "SDK", "спецификация", "стандарт", "протокол", "API", "концепция",... който да могат да бъдат използваеми по различни начини от външни или вътрешни разработчици. Няколко от опции тук са:
- достъп на ниско ниво - например направо към mqtt брокер - получават документация на услугите, събитията, топиците и те реализират на ... Ц/Ц++/джава/скрипт/пхп/хаскел/машинописка-пред-mqttspy - каквото им е удобно
- достъп през node.js пакети - ако харесват node.js им го позволяваме - т.е. улесняваме ги - правим го защото за вътрешни цели (тестове примерно) това ни е било удобно и сме го направили вече
- достъп през що-годе стандартен протокол - дали ще е през websockets, http, TCP, OPC UA... както искат, тук още говорим за комуникационната част на фронтенда; езиците пак са горе-долу всички известни нам или тях
- достъп през желан от тях протокол или начин - тук ние правим бридж - и то точно защото не искаме да се съобразяваме с "идеи" на някой си, дето може да не пасват на нашата концепция -т.е. разкуплираме нас от тях
- достъп през нещо дето сега го няма но след 1-2-5 години е масова практика - няма как, или ще адаптираме, или ще пренаписваме - НО ТОВА не значи отсега да приемем че редовно ще пренаписваме
Нямаме лукса да можем да диктуваме на клиентите си - "ще трябва да вземете ей тоя php код и само ако го вземете ще станат работите". При нас клиентите никак не обичат да им налагаш твои идеи, концепции или каквото и да било. Хващат си чуковете и си заминават (или те напъждат от техния офис щото аз като никой съм отишъл да има предлагам да купуват от нас а не от някой "голям"). Не че са лоши хора - просто всеки който се има за "голям" ги е овързал с неговите си концепции и го държи за врата. А някой от тези големите са такива че си пускат IEC/ISO-та като направят нещо - върви после се бори с тях.
В тоя свят номера е да "откраднем" нещо от пая на тия големите - щото 50-100 ентусиаста с raspberry pi не стигат да ни хранят. Не са нашата таргет група.

Има си стандарти - тук съм съгласен. За примера ти с html - да, стандарт е и да, все още живее по една причина - описва само един аспект от нещата, без да се меси дали на php, node.js, статично, мобилно, евентно, или как някой ще генерира тоя html и кой ще го гледа - дали ще е нетскейп или едж. Това си е принцип и между другото това се смята за една от причините mqtt да е още жив - не налага, не си позволява, не се опитва да дефинира други аспекти. Той се ограничава до транспорта на събития. Какво носят данните е отделна задача. Дали и тя трябва да се стандартизира, или поне специфицира, е отделен въпрос.
HTML не налага да го ползваш от определен броузър, от определен език или ОС - той се занимава с неговите си неща. Дали с твоя инструмент в твоята реализация е станало ОК няма общо със стандарта. Разбира се има и калпави стандарти - стария вариант на OPC беше цветущ пример - OLE/COM щото тогава (преди 15+ години) линукс и броузъри нямаше в индустрията - да се ограничи само до windows не е изглеждало като голям проблем. Всичко на polling - еми с кофти стандарт няма как да стане цвете. Ако единствената опция е да poll-ваш периодично сървър на другия край на света няма как да стане "динамично".

Сигурно по тази причина стандартите се развиват и допълват - опитай да си свършиш работа с броузър отпреди 15 години, дето примерно няма js, няма TLS и т.н. Ако стане някъде ще е "бяла лястовица" и определено няма да искаш да си вкараш номера на банковата карта там. А това че работи на новия броузър значи само че цялата концепция работи, говори положително за отделните компоненти (стандарти) но не изключва шанса отдолу да е феноменална боза с кръпки навсякъде.
HTTP си има своите кусури и затова някой някъде се е сетил да го разшири с CSS, client-side и т.н. Едва ли е било лесно в началото и се е получило защото е подкрепено от някой голям - това е добра стратегия ако си "голям" - ако държиш половината от пазара на броузъри ще прокараш нещо. Иначе (разбирай, като нас) ще се ослушваш за някой лек бриз който понамирисва я на гугул, я на Бил, я носи полъх на сураттефтер. И ще работиш да хванеш тая вълна и да изплуваш на малко по-плитко.
Щом даваш за пример html не виждам за какво спорим - node.js е силно ориентиран към него. Какво искаш да кажеш - да хвърля node.js щото е силен в html/http и да отида на PHP щото е силен в html/http? Е къде е разликата? Има повече хостинг за PHP? Да, така е, но те имат малко по-друг фокус - лични странички и подобни - поне това е което е евтиното като услуга. Не казвам че PHP и SQL не стават, не виждам грам предимство в тях. Може би че ще мога да хвана някой "уеб програмист" да ми напише нещо.
Ще дам конкретен пример, като се извинявам че откъм PHP не съм направил сериозно проучване и мога да бъркам - за node.js както казах има MQTT (брокер и клиент), има OPCUA (сървър и клиент), има modbus, има модули за достъп до PLC-та на сименс и ваго. Това са технологии които идват като задание отсега - за мен това е + за тази постановка. В полза на PHP за момента е че има евтин хостинг - дето независимо че е евтин няма да го ползвам защото ми трябва сериозен доставчик. Дали са 3 или 300 на месец не е аргумент - дали са 98% или 99.99% вече е.

В конкретния случай (справка - заглавието на темата) обсъждаме на какво мирише в едно ъгълче на технологичния свят в момента. За мое най-голямо съжаление не сме от стартъпите в тая област и нямаме феноменални идеи (поне не в тая област ), нито подходящи ресурси (като специалисти). За момента трябва да предложим решение (като интегратори по-скоро - т.е. не целя да правя аз "облачна архитектура" която да продаваме на други фирми). Бош имат подобен продукт - Bosch IoT Cloud, други конкуренти също.

Относно дали съм наясно няма да коментирам, казах вече знам че нищо не знам - и затова не се чувствам компетентен да изключвам инструменти, подходи, езици без да ги проуча .
Това си е нова област за мен, а и за фирмата (досега за подобни цели сме ползвали продукти на поддоставчици). Проектът е в начална фаза на research и има много за "проучване".

Усещам че не ме разбирате, ама изобщо....
В крайна сметка си е ваша воля какво и как ще го правите. Аз се обаждам щото имам доста опит на тема "устройство-сървър-клиент" и ми се е налагало да правя или да гледам какво ли не на тая тема. Въпреки целия си опит досега не съм срещнал НИТО една система дето да стъпва върху сложни неща и да е работеща. НИТО една. И въпреки всичко 99% от дизайните са такива. Що бе хора? Що все невъзможното се мъчите?
Имаш устройство/устройства, каквото и да е то. То трябва да си обменя данни със сървър/сървъри. Имаш и клиенти дето искат да гледат и да барат през сървъри и/или или директно.

Подобна ли е картинката? И ако да, кое по дяволите изисква сложнотии и мощности?

Е да де, кой говори за мощност?
Аз говоря за елементарен MQTT брокер у средата (83К е). Оттам има модул който да извади данните от нашето устройство и да ги публикува към MQTT - това колко сложно ще стане зависи колко далеч е ембедед софтуера ни от MQTT (event/publish-subscribe) - тука няма дискусия, ако системата не позволява нотификация за събитие а дава само полинг ще трябва да се пише детекция през полинг или да се преработва, това не е мъка.
От другата страна имаме фронтенда - колко сложен ще се получи зависи от какво се цели. Ако се очаква комплексна графика на цял завод, с графики и разни подобни шукарии - например SVG рисунки и анимации на всеки механизъм в машините ще стане сложно. Ако трябва да светва една лампа от зелено на червено при грешка може да стане елементарно.
Ако се очаква за фронтенд да е чист броузър (HTML5) ще трябва да се прекара до html5 - тук node.js с библиотеките които palavrov пусна е лесното за работа, и изглежда добре. Ако фронтенда трябва да е някакво приложение (андроид/дектоп/ios) може да се пише и такова - то ще консумира същите web service-и които ползва и броузърската идея - през websockets по всяка вероятност за производителност, ако няма нещо файруолско. Т.е. пак html5 само че вграден в приложение - може да се напише и на native GUI библиотека която да се храни с данни от web service-ите.

За централната точка - MQTT си мисля че е ОК. Останалите неща ще ги гласим.

Едит: сложно става когато това нещо трябва да е отворено за разширение към външни фирми. Пример - доставяме устройства, направо цяла система от устройства. Клиентът иска да си сложи сървърът при него - тука удряме на това ИТ-то на клиента да приеме нещата. Не е лесно - ти им кажи "еди къде си е сегашния сървър" (някой hosting примерно) и ти посочват вратата. Ма той много евтин, много надежден, няма как данните да ги видят... Не, или при нас на еди какво си желязо/виртуалка или ... НЕ!
Добре, ей ви го, ей ви и документация как се конфигурира - услуги, достъпи. А, не - ние ползваме IIS със еди какво си и оторизациите идват през еди каква си услуга (LDAP или там разните) - тях ще ползвате. Имаме си права в домейна или на еди къде си, ще ги ползвате тях. Харесваш или не е безинтересно за останалите.
Примерите може да се неподходящи, но въпросът е че ние като доставчик (продавач на стока) трябва да задоволим купувача. И ако неговото IT, или сервизен техник дето до вчера е метял стружките покрай машините каже - "това не става, аз не мога да се оправя с него" се връщаш и имаш две опции - теглиш им една на простите некомпетентни идиоти, или си сядаш на дъ-то и мислиш как следващия да му го пробуташ.
Когато контролът е в твоите ръце правиш както смяташ за добре, когато трябва да излезеш нанякъде без да знаеш даже накъде, мислиш как да го извъртиш така че да покриеш всички възможни (предвидими към момента) сценарии (т.е. клиенти, т.е. пари). Винаги има неща които не можеш да предвидиш - и е възможно в един момент да се окаже че си взел феноменално грешно решение - това се разбира след време, и ако това време е било достатъчно да изплати труда ти - ок. Натрупал си опит и отдаваш грешките на растежа.

Може да се разработва за мобилни платформи пак с ноде - едното даже е българско творение, виж тука:
https://www.nativescript.org/
https://facebook.github.io/react-native/
В този случай node се ползва само на дев машинат - после на смартфона се търкаля лек клиент. Не е идеално решение но пък не ти трябва да инвестираш много за да подкараш някакъв елементарен апп.

Ценно, видях че има някакви опции за native и с това featherjs дето го спомена:
https://docs.feathersjs.com/why/showcase.html
То май е вързано точно през React-native.
Ще ги огледам и тях, пак благодаря.

ех, момчета, момчета...

Иска ми се да ви видя лицата след няколко реални клиента

Ми ... всеки има право на лош вкус

Още 2 линка в случай, че за фронт енд решите да стъпите на react

https://preactjs.com/ - това е много лека алтернатива - 3кб срещу 70кб копресиран js - разликата е огромна а върши почти същата работа. Та от документацията на този преакт има много добро обяснение какво е и как работи JSX - https://jasonformat.com/wtf-is-jsx/

Сега може да ти се стори шантаво, но след време ще ти светне колко елегантно са го направили фейсбуците.

така е, всички летим в облаците, докато реалността не ни приземи

Аз просто споделям опит... част от който не съвсем добър, от там идва и по-голямата доза песимизъм може би. Значи gicho e дал разни примери за "капризни клиенти". Проблемът е, че няма два еднакви клиента. Особено ако им се налага да обслужват от големи корпоративни до малки цехчета. Разликите са от небето до земята. И много трудно се проектира система дето да може да се скалира от едната крайност до другата.
Тъй като ми се е налагало да проектирам такива неща бих препоръчал на gicho вместо да се занимава с програмирането да вземе един бял лист, да нарисува три кръгчета (устройство-сървър-клиент) и да седне с някой мениджър да обсъдят кое как ще се прави, как ще се продава и как ще се поддържа след това. Много от комбинациите просто ще отпаднат от само себе си. Хубавото в моя случай беше че първо трябваше да направя спецификация какви ракове и с какво трябва да се напълнят, после с какъв софтуер и т.н. Като седнеш и като видиш как се прави примерно load balancing и колко хора могат да ти го направят и с какво и на каква цена и картинката се изчиства. Не че няма различни варианти на теория, но на практика предвид наличните хора и средства изборът ми се сведе точно до 1 комбинация.
Според мен да се сложат неща в заданието като MQTT, node.js и т.н. създава голяма опасност после по копчето да се шие балтон. В центъра не го виждам да е MQTT-то. В центъра обикновено стои SQL-a. Евентуално няколко SQL-а, щото има случаи в които хората искат М$, други МySQL в трети postgre. Но да кажем, че ще се сетят да си направят някакво API, което да позволява тоя или оня sql. Въпросът беше че базата данни обикновено е центърът. Ако тя стабилна отгоре може да се слагат много неща, но ако там сгафиш и ти се омазват данните всичко рухва.
От гледна точка на кръгчето с клиента, ми аз не се сеща за какъвто и да е веб инструмент дето да няма поддръжка за SQL. Няма и вебаджия дето да не може или да не ползвал SQL. Тъй че връзката SQL сървър <-> клиент може да е абсолютна всякаква. Не си струва даже повече да я коментирам. Ако щете вкарайте по средата node.js или MQTT ако мислите че това ще допринесе с нещо.. Но за мен това е просто един от хилядите варианти и нищо повече!
От другата страна... устройство <-> сървър. Както казах за мен сървърът е SQL, но устройството не е желателно да маже директно така че трябва да има нещо по средата дето да превежда от езика на устройството (протокола) до операции с базата. Това нещо по средата всъщност трябва да са мноого неща, защото най-вероятно устройства ще са поне няколко типа по поне няколко версии. Желателно е отделните преводачи да са независими а не едно общо приложение. Обикновено се ползват различни URI-та за всеки тип и т.н.
Може ли между устройство и сървър да има MQTT .... ми може, що да не може. Може ли на сървъра да има node.js за посредник - може... Ама въпросът е нужни ли са тия неша? Ако са нужни слагайте. Аз нямам идея, само казвам че нещата трябва да са възможно най-прости и изчистени. И в тоя смисъл не виждал къде е келепира...

направо си хвърчат

Облак.... е "база данни" която приема еднородни обекти(текст, картинки, музика) със "слабо" индексиране по узер, вид, дата... нали?
Не събира протоколи в които има незнайно какви обекти, променливи и събития

Той е евтин, надежден(MQTT)... тук изгубихте по точки, Евтин е да го копи/пасте, тръгнеш ли да го модифицираш загуби доста време и нерви, следователно пари
След модификацията надежноста намалява а след време усещаш как си настъпил мотика и не можеш да адднеш еди какво си устройство.

Мога да ти пиша още негативи - защото ги знам, знае ги и Миро и още които ги мързи да пишат...
Позитива е да експериментираш и да видиш какво се получава наистина и чак накрая да събереш идеите в някаква единна система