Dear all
does http-response have to work with http-in node? my flow invoke http-in, then http-in invoke mqtt-out. then i get data in mqtt-in which is another flow. at this time may i send the data back via http-response?
msg.res from the http in nodes has to make it to the http response node. You can use a join node to combine the two payloads, which should pass msg.res through as well, or save the msg.res some how and add it back prior to response node.
I'm not sure that join would work here. You should note that the req/res objects have circular references. While this is allowed in JavaScript, it is not allowed in JSON. Since there are various places where objects have to be serialised, Node-RED automatically removes the req/res objects at those points to prevent otherwise unrecoverable errors.
The better way to do this would be for your MQTT-in node to update a flow variable and for your http-in/-out pair to have an intermediate change node that grabs the flow variable and adds it to the payload. That way, any request gets the latest MQTT data.
http-in -> change (add flow var to payload) -> http-out
+-> mqtt-out
mqtt-in -> change (output data to flow var)
May be you should test it, as I have it working fine.
Using either method it may pay to add some concurrency.
1 Like
it is amazing. work now. thanks alot sir.
hello sir. i test it, save msg.res in global, when i get mqtt-in i read res in global and set msg.res = res, then http-response node work. thanks you anyway, you are very nice and excellent at work.
No, that won't work unless you can be absolutely certain that no other calls will come in before the response goes out.
Remember that you could have thousands of people hitting the endpoint almost simultaneously (if it is public or in a large enterprise).
In addition, you can only store msg.res in memory and it can be quite large - might be an issue on a limited device. We don't know your infrastructure of course. Trying to write to disk or using one of the other storage mechanisms will cause it to be serialised which will either fail or might result in missing data.
Doing it the way I suggested is also more efficient. And will be more robust as you are decoupling the MQTT data from the request/response.
Both methods would need some concurrency checks/limiting.
Why don't you just use Link nodes to link across to the other flow, rather that using MQTT?
Not really. My method's only limitation revolves around update timing of whatever MQTT data is being consumed. But the process will always deliver the latest result (within a few ms) back to a request with minimal latency in the response because the data is already in memory.
Any other performance issues would be the general ones you may get from using Node-RED as a web server.
So you save res to context while waiting for mqtt response, if new http in comes along in the meantime then res would be written over, so some form of concurrency or rate limit would be required.
No, my option is the opposite! Saving the res or req is error prone and big. Save the MQTT output instead.
As shown in my little diagram above.
And how does that allow the result of mqtt in to be sent in the response?
Sorry, its been a long and arduous day. I explained it in my post, not complex, there is even a diagram. Write the MQTT input to a flow variable. Every http request gets the latest data from the variable.
I feel for you, but i still fail to see how any response from the mqtt in gets sent to the http response node. I even built an example, to make sure i was not missing something.
If the mqtt in is a response and not the same data sent in the mqtt out node, how does your method (as your diagram) pass the mqtt in new data to the http response?
To what? The only output from the http-in is an MQTT out and you don't do an MQTT out just to get the same MQTT in, that would be pointless. So the MQTT in must be some other data. If the original example is outputting some MQTT in order for some other process to create a different MQTT output (something not shared with us), that would raise a whole load of async timing issues and would not be recommended.
MQTT is a publish and subscribe tool. So the -in is a subscription and data will appear when something else updates that topic(s) - when it does, my flow captures that and holds it in memory ready for use. Then when someone triggers the http-in request endpoint, they are immediately given the latest MQTT data which is cached in memory.
As far as I can tell, the examples shared by others above all have the same potential issues. http-in to http-out should be a short latency. Also it is perfectly possible to have (particularly at higher latencies introduced by delays in the flow) multiple http-in messages in-flight before previous http-out processing has completed. Imagine 5 people refreshing the web-page at the same time. The interlocking flows make that potentially fragile and slow.
The alternative I suggested will never slow down the performance of the web endpoint because all it is doing is using an existing in-memory object and passing it direct to the output.
This means that the web process and the mqtt data process are decoupled.
I would think that the mqtt is a command or a api call, it then responds with a status or api return, which then would be returned to the http response. Otherwise why have the mqtt at all, just wire them .
That's exactly my point. And this data should be returned to the http response.
Your diagram will never return the mqtt status/api response to the http response, which I assume is the point of the http endpoint and subsequence mqtt call.
I see no examples just images and diagrams.
I think we are both assuming different things. Unless the original question is updated, we cannot know.
What I do know is that the other examples shared (as images to be clear) are fragile and will, under some circumstances, fail with odd results.
I assumed the mqtt in would need returning, I was unclear on what you assumed. I think I got it now.
i asked you how you diagram would return the mqtt in to the response, I ask/clarified, I think 2-3 times, but still you have not responded with a responsive reply. You may of been thinking in your little diagram that the mqtt in is not to be returned, that's why I asked, so i could get a clarification. I take it from your lack of direct response to my question, that your diagram would not return the mqtt in data to the http response.
I didn't respond because I'm not sure why you think that?
mqtt-in -> flow-var
Flow var now contains the mqtt in data. a change node between http-in and -out retrieves the contents of the flow var and so does indeed get the data and passes it back to the requesting web client.
