I am building a sidebar plugin for Node-RED called node-red-contrib-protocol-inspector — a DevTools Network-tab-style inspector that captures and displays HTTP, MQTT, and WebSocket traffic flowing through your flows, via monkey-patching (no changes needed to existing nodes).
Current features:
Live traffic capture for HTTP, MQTT, and WebSocket messages
Filterable, searchable request/response log
Payload inspection (headers, body, timing)
Before I lock in the feature set for a wider release, I would love input from people who actually debug flows day-to-day:
What protocols/node types cause you the most pain to debug today? (Serial, TCP, custom nodes, etc.)
What would you want to filter/search by — node ID, topic, status code, payload content, something else?
Would you want export capabilities (HAR-style export, copy as cURL, save session to replay later)?
Any interest in request/response diffing or highlighting changed fields between messages?
Should it integrate with msg._msgid to trace a message across multiple nodes in a flow?
Performance concerns — how do you feel about overhead on high-throughput flows? Would a sampling/rate-limit mode be useful?
Any thoughts, pain points, or "I wish DevTools could just—" moments are welcome. I am trying to build something the community actually needs, not just what I assumed they needed.
I've done that using message tracing with my introspection package. That basically covers all use cases I have for inspecting live traffic through my flows.
It also integrates the debug panel, so I can do all my filtering using that panel.
When I started talking about message tracing here in the forum, that was the first comment: don't do this, it will kill the editor performance. Well it didn't but just in case it does, I did recently add rate limiting to it.
Even if there is a risk of performance degradation, a little clarity/insight can go a long way so the trade off is probably well worth it.
Overhead: The inspector monkey-patches http.request/https.request, the MQTT client send/receive, and ws send/message at the module level, so it's just wrapping existing calls to log metadata (timestamp, direction, size, headers) into a ring buffer — no extra network hops or serialization of payloads unless you expand an entry. Should be low single-digit % CPU overhead even under load, but I haven't benchmarked it formally yet — I'll post numbers.
vs. Chrome DevTools Network tab: DevTools only sees traffic from the browser (admin UI), not what Node-RED itself is sending server-side — MQTT, outbound HTTP from function/request nodes, WebSocket traffic to external brokers/devices. This plugin captures the runtime side that DevTools can't see at all.
vs. debug node output: i catched myself over the years shipping flows which constantly needed updating, a good habit was not including debug flows, and every time updating was several minutes of adding nodes, debugging, deploying.
Non-core nodes (UIBUILDER, Dashboard 2, etc.): Since it patches at the Node.js module level (http/https/ws/mqtt client libraries), it should work with any node using those standard libraries under the hood, including UIBUILDER and Dashboard 2 — not something I've explicitly verified against every contrib node yet. If you're up for testing UIBUILDER specifically once I push a build, I'd appreciate it.
Thanks Gregorius, that's a solid reference point. A few differences worth noting for people comparing them:
node-red-contrib-introspection traces messages within your flow (node-to-node), routed through the debug panel. protocol-inspector targets the layer below that — actual wire traffic (HTTP requests, MQTT pub/sub, WebSocket frames) via monkey-patching the underlying clients, surfaced in a dedicated DevTools-style sidebar rather than the debug panel. So it's less "what did my function node output" and more "what actually went out over the network, with what headers/timing."
Good to hear rate limiting solved your perf concerns — I'll likely need similar throttling once WS/MQTT volume gets high, so that's useful precedent. Appreciate the pointer to the message-tracing thread, going to read through it.
Perhaps another idea would be to have a clamp mode whereby highlighting nodes immediate generates debug details - also something that I implemented later for the message tracing. Most importantly is of course that all features work without having to deploy - else you might lose bugs by redeploy. Something that I would recommend for the usefulness of what you're doing!
This might be non-trivial - I don't know how you implement the monkey patching. The message tracer can do this because I hook into specific events that are generated for each message, so I can turn it on/off at runtime without deploying.
One thing to note is that UIBUILDER and, I think, both of the Dashboards all use Socket.IO rather than websockets directly. Though, of course, Socket.IO is usually configured to prefer websockets. Don't think that will be a particular problem but worthy of note anyway.
Annoyingly, while Chromium dev tools for node.js does include a network tab. It is in preview and does not appear to show any Node-RED network activity, at least on my Windows dev setup and using Vivaldi browser.
