My team at DPG-Media have a question about the way we need to deal with something we encountered implementing the YJS-websocket-provider in our codebase. We have a frontend setup which uses SyncedStore and the yjs Websocket-provider to setup a communication between clients and a websocket-server. The communication goes pretty well, aside from some quirks.
One of these quirks, we discovered when debugging, is that minifying the tab or leaving the tab will cause the websocket connection to send a on 'close' message to this server after a certain amount of seconds.
The way we implemented this now is with the idea that a on 'close' really means no connection at all, thus the tab closed, the application stopped or the internet connection is lost. This led us to some issues, since a close was believed that nobody was actually having a browser open anymore. There has been logic build upon this assumption, that executes a cleanup functionality when not a single websocket is connected anymore, removing and destroying the YDoc to which all these clients have been connected to.
We are now looking for a solution to prevent this cleanup from happening and find a better way to handle and interpret the closing of a websocket message. The reason is because we have found a bug where there are 2 users working on a document, both minifies their tabs, and both send a on 'close' message to the websocket server. This cleans up the document. Then client A opens the tab again and is able to continue to work on a new instance of this document. Client A then closes the browser. Client B now opens its browser, but is not able to get its changes from the Client A and can start working on the document with the changes from Client A being dismissed.
We hope for guidance in this setup, since we lack the true knowledge of how the YJS websocket-provider works under the hood. This lead to some questions we don't know how to answer without assistance:
How do we have to interpret a on 'close' message send by the Websocket. Do we have to assume a close isn't actually a close, but a temporary leave and should be in sync again the moment the tab gets opened again?
What is the best practice on cleaning up an Ydoc shared between multiple clients? We don't want Ydocs hanging in memory when there is nobody working actively on these documents.
Is it normal that when you have your tab minified and changes are send to the server and clients, when you open your tab again, you don't get these updates on the client-side? Do we have to built-in some mechanism to deal with new changes when opening the tab again? Or is something wrong with the sync1Step and sync2Step? We would expect that reconnecting to the websocket server would load these new updates into the front-end, but that doesn't seem to happen. It might be a bad implementation on our side as well.
Hi there!
My team at DPG-Media have a question about the way we need to deal with something we encountered implementing the YJS-websocket-provider in our codebase. We have a frontend setup which uses SyncedStore and the yjs Websocket-provider to setup a communication between clients and a websocket-server. The communication goes pretty well, aside from some quirks.
One of these quirks, we discovered when debugging, is that minifying the tab or leaving the tab will cause the websocket connection to send a on 'close' message to this server after a certain amount of seconds.
The way we implemented this now is with the idea that a on 'close' really means no connection at all, thus the tab closed, the application stopped or the internet connection is lost. This led us to some issues, since a close was believed that nobody was actually having a browser open anymore. There has been logic build upon this assumption, that executes a cleanup functionality when not a single websocket is connected anymore, removing and destroying the YDoc to which all these clients have been connected to.
We are now looking for a solution to prevent this cleanup from happening and find a better way to handle and interpret the closing of a websocket message. The reason is because we have found a bug where there are 2 users working on a document, both minifies their tabs, and both send a on 'close' message to the websocket server. This cleans up the document. Then client A opens the tab again and is able to continue to work on a new instance of this document. Client A then closes the browser. Client B now opens its browser, but is not able to get its changes from the Client A and can start working on the document with the changes from Client A being dismissed.
We hope for guidance in this setup, since we lack the true knowledge of how the YJS websocket-provider works under the hood. This lead to some questions we don't know how to answer without assistance:
If more info is required, please let us know.
Thanks in advance!
Huly®: YJS-553