How to update local parse.com database incrementally?

Question

i have a parse.com based app with offline capabilities where the whole database is stored locally (localStorage on web clients and parse.com local database on mobile clients). I am looking for a design solution to efficiently update the local database with latest changes in the remote database. The options that I could think of are:

1. Journaling with code triggers. Setup cloud code triggers (afterSave, afterDelete) for every object and add a log to the journal table every time an object has been saved or destroyed. The clients will query the table for updates and remember lastUpdateTime for subsequent requests.

   Pros: a) we can have a very detailed summary what has been changed and who made the change. b) all the changes are instantly available for other clients (e.g. table call be polled for notifications in real time with little delays)

   Cons: a) there may be too many entries in the table

2. Journaling with background job. Setup a background job that queries all tables by updatedAt, populates journal table and saves the lastUpdateTime for subsequent requests.

   Pros: a) less entries in the journal table

   Cons: a) changes are available with unpredictable delay (not suitable for real time notifications?) b) cannot track deletes, there's still a need to setup another table to track deletes or implement soft-delete c) less details in the log (e.g. when object is created by one user and deleted by another user, we will not know who created an object)

3. No journal. All clients query all tables by updatedAt and store lastUpdateTime for subsequent requests.

   Pros: a) easy to implement, b) changes are instantly available

   Cons: a) same problem with deletes as in 2, b) inefficient (i believe that querying 20+ tables by all clients is not a good idea

We also have an UI where user can look through the recent activity (who changed what), so I kind of lean towards number 1 approach, but the potential size of the table is worrying me.

Answer 1

Client needs ability to recover irrespective of current state. This is critical if you are using local storage that may get cleared by the user. In that case you need a recoverable state. Additionally the client needs to be able to fetch only the transaction required / relevant to it.

1. Implementing a transaction store on the backend
2. Creating a recovery mechanism in case the localstorage offline is corrupted
3. Journaling with code triggers or use of event source db type mechanism so that you have complete history and can use that to build tables for the client.

In conclusion - Modified Journaling with Code Triggers (Modified to recover and storing the state for client in server and using that to query the data)