Here are the Required Model Fields to include in every Data Record if you want to Sync (Synchronize) Data Records to Custom Back-End Programmatically – (without Private Clouds):
On The Front-End
To be able to Sync the Data – on every Client and Each Client Device or Software – each Data Record must have the following fields:
- Is Synchronized – a True or False Flag – that indicates if it the record has been changed after the last synchronization.
- Is Deleted – a True or False Flag – indicating that the record has been removed locally. After successful synchronization, this record could probably be wiped out permanently.
- Date Created – Timestamp of Date of Creation
- Date Updated – Timestamp of Date of Change
- GUID – a Global Unique Identifier string. A single Auto-Incrementing Integer will not work. If you decide to use numbers as data record uniqueness – you will need at least two IDs (local and server).
On the Back-End
The simpler way for implementing the server-side part is to treat the back-end as another node. Then, the fields from the client may be sufficient to complete the synchronizing algorithm. In this case wiping out permanently the data records may not be a good idea, because it will most likely break the consistency and reverse user actions inappropriately.
There is another option you could choose – to make the server a Super Node. Then, the back-end could store the above data for every record AND also have model with name “Node” with properties:
- Last Synchronization Date,
- Client Node ID/Name,
- More custom fields according to the needs.
This will allow the Server to send Push Notifications to the Client Nodes who have data out of sync – depending on the business logic need. It may be even in real time or the requirements may be – after some time of no communication.
The Sync Data Algorithm
On every node there should be single timestamp to indicate the last time of synchronization. If a node is new – the variable value is 0. After successful synchronization it should get updated with the current time. Probably the more secure source of the date fields is from a server because of time zone issues or even there is a chance that the user has changed the time setting of the device.
- The logic when a record is new will be insert.
- When the user has updated only one of the node’s data – after the last synchronization the action should be update/delete (or mark as).
- The most tricky use case you need to handle is when a record has been changed on both synchronizing nodes after their last communication.
- The first choice is to always update according to the date updated field and lose the changes from the other node.
- The second choice is keep both variations and let the user decide which one to keep (he may choose to keep both).
- The third alternative is – if the data model allows it – to grab the changes from both nodes and merge them together. This type of synchronization is very successfully handled by the Source Control Software – Git.