The Guide to building Sync-friendly APIs(xkit.co)

7 pointsby tg3hace 4 años4 comments

The Guide to building Sync-friendly APIs

https://xkit.co/blog/the-guide-to-building-sync-friendly-apis

3 comments

cthebhace 4 años

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.

ivanvanderbylhace 4 años

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.

zmjhace 4 años

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

saurikhace 4 años

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