artman

https://github.com/jakearchibald/idb is a nice low-level wrapper for IndexDB that promisifies the API without much performance overhead.

The HTTP request is fired off instantly, so chances are that the request is already written to the socket and closing the page won't cancel the request. Should your wifi-router drop it, your client will retain the transaction on disk and retry it the next time you come online.

Operations are on average applied within a few hundred milliseconds, and almost never fail. Because of this we treat the success path as default, and indicate that your changes haven't been applied only if we detect that you're offline, or if it takes more than 4 second to apply the changes.

In reality conflicts almost never happen.

Changes go through and synced to everyone on your team in almost realtime. If there's a conflict on the server and your change cannot be applied (almost never happens), your change is rolled back on your client, again, almost in realtime. If servers cannot be reached, we will show you a syncing badge within 4 seconds to tell you that you have made changes that haven't been sent to others yet.

Strange that we can be so be polar opposites on this. You hate it, I would never write an app in any other way, ever again.

For inspiration, you might want to look at what we open sourced at Uber, https://github.com/uber-archive/jetstream-ios and https://github.com/uber-archive/jetstream/wiki/Protocol. While pretty immature and quite outdated nowadays, it did power one prototype in production and has a lot of the same concepts that we later used in Linear's sync engine.

I think the impressive part here isn't Linear's sync engine, but the fact that Evan Hu went through painstakingly reverse-engineer the engine by inspecting traffic and obfuscated code and was able to write documentation that is correct and more complete than what Linear publishes internally.

Most certainly, if the data that the mobile app consumes is bounded and the same data is accessed frequently. Uber for example could have benefited from a sync architecture immensely (I tried to implement one back in the day, but was too late to the party as hypergrowth blocked any attempts at switching architectures). Sync architectures are not only great from a user experience point of view, but also for developer productivity and velocity. Sync takes care of a slew of problems that makes feature development slow. I gave a talk on this at last year's Local First conf https://www.youtube.com/watch?v=VLgmjzERT08&t=4s.

We unfortunately don't currently have plans to provide self-hosting.

Very nice!