Term: Asynchronous Synchronisation #9

Open
janl opened this Issue Nov 28, 2013 · 4 comments

Comments

Projects
None yet
4 participants
@janl
Contributor

janl commented Nov 28, 2013

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

This comment has been minimized.

Show comment
Hide comment
@mitar

This comment has been minimized.

Show comment
Hide comment
@mitar

mitar May 17, 2015

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.

mitar commented May 17, 2015

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

This comment has been minimized.

Show comment
Hide comment
@gr2m

gr2m May 18, 2015

Contributor

@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.

Contributor

gr2m commented May 18, 2015

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment