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.
While, mildly interesting, I don't think this can really be relied upon in practical terms. It might be nicer if this were a linting tool to ensure that public (exported) classes and methods are indeed documented, provide generated comments, and flag for review before it can pass linting (have to remove the @autogenerated tag).
In the end, I think AI developer assistants are going to become more common... been playing with the Github extension for VS Code, which I haven't had much use for, but it is interresting.
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