Hi @jstleger0,
The resyncInterval was requested by someone who noticed that messages get dropped over websockets. There was a deeper issue in some component that was responsible that some data was lost (I assume the proxy, I don’t know…). TCP / WebSockets connections don’t just drop messages.
However resyncInterval was a quick and cheap solution for this edge case, as you simply perform a full sync in some interval. This really is not necessary. It would make more sense to fix the underlying issue.
After sync is fired, you should assume that the client received all content from the server. There is no message that confirms that a server really received all updates from the client. That is something that you would need to implement yourself.
If this is really important to you, you could extend the sync protocol and give each update that is sent from the client a unique identifier. The server must confirm that each message has been written to the database before the client shows a sync message. This, however, only makes sense for super sensitive content.
Shouldnt
wsProvider.on('sync', () => {})be called for everyresyncInterval? If this was the case we could show a last synced time…
Realtime documents should always be synced in realtime. There is no need to show a last-synced timestamp. Though, it does make sense to notify the user when they go offline (listen for the provider.on('status', status => )) events. You could show something like “you have been disconnected for … seconds. Unsynced changes won’t be persisted.” before closing the browser. Everything else is probably overengineering.