I'm building a web client to node-red where I'm running mosca MQTT broker.
I'd like to be able to subscribe in the UI client to various topics and process subscribed messages locally within each UI module rather than worry about dispatching them from a shared mqtt.onMessageArrived handler.
Perhaps adding an onMessageArrived option to the subscribe call would make sense for this?
Internally, Paho.MQTT would route incoming messages to that handler if the topic matches subscription filter.
Or, subscribe could return a mediator object that would have its own onMessageArrivedhandler as well as publish method, which would automatically set the topic based on the subscription? However, this may be an overkill and a problem if subscription uses wildcards.
Just started looking into a similar problem. Routing messages of varying payloads to UI components that are interested in them is not a trivial task given the current architecture.
I'm building a web client to node-red where I'm running mosca MQTT broker.
I'd like to be able to
subscribe
in the UI client to various topics and process subscribed messages locally within each UI module rather than worry about dispatching them from a sharedmqtt.onMessageArrived
handler. Perhaps adding anonMessageArrived
option to thesubscribe
call would make sense for this? Internally, Paho.MQTT would route incoming messages to that handler if the topic matches subscription filter.Or, subscribe could return a mediator object that would have its own
onMessageArrived
handler as well as publish method, which would automatically set the topic based on the subscription? However, this may be an overkill and a problem if subscription uses wildcards.