Describe how onDocumentChange works and add it to the documentation

[thesunny]

I can't remember if we specified it like this, but I think onDocumentChange should only be executing continuously in one editing session. This would allow us to throttle and also to avoid duplicate processing of the same document changes.

We could have one editing session always be a master session.

• User "A" starts editing. He is the master. onDocumentChange is called for all the edits.
• User "B" starts editing. User "A" is still the master. Any changes made by user "A" or "B" has the onDocumentChange called from the editing session of user "A" (in a multi-Node scenario).
• User "A" ends the editing session. User "B" becomes the new master.

Etc...

If this is the way it works @wleroux I'll document it. I'm working on the documentation for saving onDocumentChange and was going to write in how to throttle using lodash's throttle method. Of course, this wouldn't work if onDocumentChange is called from everywhere.

• [ ] Clarify how onDocumentChange works
• [ ] Add to GitBook documentation

[wleroux]

The onDocumentChange is executed on the server that is handling the changeset for a specific user. That server may not be handling all changes to that specific document however. Throttling is not possible between all users modifying the same document in a cluster configuration.

Other solutions can be implemented to address this need, should it be required. As the throttling can occur between users on the same server, this most likely resolves the majority of concerns RE: overloading downstream services. Additional services may be created downstream that have sticky sessions based on document identifier that would throttle there. In conjunction with the revision being sent, the downstream service can always ensure they are only saving the most up-to-date document.