How to Sync Data to Custom Back-End Programmatically

Sync Data

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.
  1. The first choice is to always update according to the date updated field and lose the changes from the other node.
  2. The second choice is keep both variations and let the user decide which one to keep (he may choose to keep both).
  3. 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.

Leave a Reply

Your email address will not be published. Required fields are marked *