Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Term: Asynchronous Synchronisation #9

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

Term: Asynchronous Synchronisation #9

janl opened this issue Nov 28, 2013 · 4 comments

Comments

@janl
Copy link
Contributor

@janl 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
Copy link

@michielbdejong michielbdejong commented Dec 18, 2013

+1

@mitar
Copy link

@mitar 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
Copy link
Contributor

@gr2m 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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.