The Guide to building Sync-friendly APIs

xkit.co

7 points·tg3··4 comments

In a distributed system it may not be appropriate to rely on a timestamp like this without accounting for the possibility of clock skew (unless the system provides a guarantee that timestamps are monotonically increasing.)

SQL databases have had auto increment columns for ages, and they can be used to help with this problem.

For a “guide” I wish it would discuss some of the pitfalls of the presented approach along with alternatives.

There are some good ideas in there, but it doesn't really address the hard parts of syncing, such as handling items that were deleted, or arrays of items that changed order.

In other words, an API that is good for syncing needs to communicate what changed, not just the snapshot of the current state.

This assumes the client's system clock is well-behaved, which is rarely true over long time spans.

I absolutely believe I could have missed something, as I only quickly skimmed this (it looked like it was going to not teach me anything non-obvious from spending a ton of time doing this kind of work), but the premise is the client timestamp is irrelevant: the parameter being passed is the previous most recent timestamp of an update seen from the server, and is merely acting as a monotonically-increasing change identifier (wherein I then agree with the other commenter here: it is weird to tie this to time and it would be better to make it opaque).

Reply on news.ycombinator.com