Term: Asynchronous Synchronisation

[janl]

For the situation that a client (be it an web site / web app or native app) stores user input (text, photos, map markers etc.) locally first and only synchronises the data with the server “later”.

Advantages over synchronous sync:

• allows for a fast, low latency user experience, as user interactions only ever talk to the local machine.
• networking errors do not interfere with the main application flow.
• applications work without an internet connection.
• save battery life because network operations can be batched.
• add more here…

Implementations:

• email outbox

[michielbdejong]

+1

[mitar]

It seems that this is what Meteor calls latency compensation.

And important property of it is that client should roll-back the change if the asynchronous action fails eventually.

Moreover, the downside is that it can give the false feeling to the user that something was saved. You click save, synchronously you show "saved", and make an async background save, which fail for whatever reason.

[gr2m]

@mitar when implemented properly, the local "save" should be persisted. Even if the app crashes, it should still be stored locally, so it can be synced in the background or at anytime later. And in case of a conflict, both versions should be available on the server, so no data gets lost, and conflict resolution can be done on any devise by the user. If user input is required for conflict resolution at all.

[michielbdejong]

See also https://github.com/slightlyoff/BackgroundSync