Deleted the duplicate posts... leaving this. Note: this is a JS content related site... see the about page[1]. While your tool looks interesting, it's really headed into off topic territory.
FTR, I've been playing with Rust, tauri and yew... the whole space is very cool along with support for wasm tooling. It's just off topic in this space. You may want to post to Hacker News[1] or other more general developer groups. Alternatively, if you wrote an article showing how you can integrate this with say package.json for a node project, or with Deno... that would at least be borderline.
1. https://www.echojs.com/about
2. https://news.ycombinator.com/
I'm not the one that downvoated, but there has been a lot of posts on this Snap Camera Server and related topics the past week, and some may be a bit overloaded and/or uninterested, then offput by the posting volume.
This is very conceptual and kind of OT... but leaving it here.
I'd thought of doing similar, by having a websocket channel and a state manager similar to Redux that simply received actions (dispatched from FE), then the state changes delivered as a stream of JSON Diffs.
One step further could be including the UI structure instead of state... though not sure if this would be very well performing at all, since that's what HTML itself represents. It's effectively what Blazor does with the server round trip configuration, and with any kind of latency it's pretty painful in practice.
Correction needed: "JavaScript Numbers are represented by IEEE 754 64-bit (double precision) floating point values, not fixed Decimal values. Because of this, some values (such as 0.3) are less precise as the fractional values used and whole numbers are only accurate to 2^52-1."
What this means is some bits (of 64) are for the whole number portion, and others are for the divisor.
For those curious, the "Dave's Garage" channel on YouTube went over the interesting history of this.
There are unfortunately some formatting issues... part of the HTML markup is posted twice, and the markdown code formatting towards the end seems to be entirely broken.
As to the content, it all seems relatively straight forward, until it breaks...
I do think it might have been better served by not introducing all the concepts in play at once... Starting with a very basic, single instance websocket server. Then explain the shortcomings and how sticky sessions are provided by socket.io, along with channels/routing. Then expressing the issues with connection scaling, and adding in cluster and the redis adapter. Why adding a worker on the server helps, etc.
Those last bits are actually questionable for the use case in question, as most bottlenecking will become IO bound on Redis, and cluster/worker may not add much as Node.js uses thread pooling for IO connections.
That said, by starting simple, and adding the extra bits, it becomes possible to separate some of the conceptual pieces that can overload someone not already familiar with those pieces and the why behind them. Also, a github repo that has commits on master matching the stages of the project would also be very beneficial.
Or... you can use the ES2022 #privateMethod(){} definition, where the hash symbol is used. It's been practically available for some time now. https://caniuse.com/?search=private%20class%20fields