No, no, no.. the NodeJS proxy Server is an Option. It's for people that have both multiple hubs and devices that are concentrated on a subset of the Hubs. It reduces the load, but if there's not much load to begin with, there's not much to be reduced either.
The EventSocket interface that is (what I assume to be) the most used interconnect between hubs has ALL the device data on it. A Connected Hub has to listen to ALL and filter down to what's selected. IF you're getting 10 devices worth of traffic and you've selected 8+ of them to be mirrored, there's not much left to filter and therefore the NodeJS proxy Server won't gain you much.
In my situation, I have a HubConnect Server Hub that listens to 3 other Hubs that have Devices. Dashboard is running on my Server hub and so I want to "see" just about every device. Thus the Server Hub is hearing about every event all across my 3 connected hubs. That's OK because there's almost nothing to filter. I want the server hub to hear about everything... and use it.. either to the Dashboard or sending it to Alexia, and Homebridge.
But the other direction is kinda scary.. the Remote Client hubs, have a portion of the devices split across them, but listening to the Server hub, they get 100% of everything too. They may only need 5% They are 'drinking from a firehose' and those are, in my case, the exact hubs I want to be really close to idle, so they react instantly to any motion or contact sensor. For me, running that through the NodeJS proxy Server saves 95% of the traffic to the connected hub.
Your architecture, your quantity of devices and your need for filtering may be substantially different from me and the NodeJS proxy Server is something you can ignore.