Local, first, forever

🌈 Abstract

The article discusses the concept of "local-first" software, which aims to give users more control over their data by keeping it local while still allowing for occasional syncing with the internet. It explores the challenges of implementing local-first software, particularly around the need for a reliable sync mechanism, and presents different approaches to solving this problem using cloud-based file sync services like Dropbox.

🙋 Q&A

[01] What is local-first software?

• Local-first software is software that prefers keeping user data local, but still goes to the internet occasionally to sync with other users, fetch data, back up, etc.
• If the software doesn't go to the internet at all, it's just local software.
• If the software doesn't work offline with data it already has, then it's just normal cloud software.

[02] What is the problem with local-first software?

• The main problem is that the online component of local-first software, such as the need to sync between devices, requires a server, which can become a point of failure if the company behind the software goes out of business.

[03] What is the proposed solution to the problem?

• The solution is to use a widely available and accessible cloud-based file sync service, such as Dropbox, iCloud Drive, OneDrive, Google Drive, or Syncthing, as the sync mechanism for local-first software.
• These services are likely to outlive any individual software company and provide a commodity file sync service that can be used as a foundation for local-first applications.

[04] What are the downsides of using a basic file sync service as the sync mechanism?

• File sync services have a "dumb" protocol with limited APIs, so you can't easily hook into sync events, update notifications, or conflict resolution.
• In case of conflicts, the best-case scenario is getting two files, and the worst-case is getting only one.

[05] How can the issues with using a basic file sync service be addressed?

• The article presents three approaches:
  1. Super-naive: Save the application state in a file and let the file sync service handle the syncing, using CRDT (Conflict-free Replicated Data Types) to resolve conflicts.
  2. A file per client: Give each client its own file, so Dropbox won't report any conflicts, and use CRDT to resolve conflicts within the data.
  3. Operations-based: Write operations into a separate append-only file, with each client only writing to its own file to avoid conflicts on the Dropbox level.

[06] What is the conclusion of the article?

• If you want to build a local-first application that gives users complete control and ownership over their data, you need a solution for data sync.
• While basic file sync services like Dropbox may not be as real-time as a custom solution, they can still provide a simple but working way to implement local-first sync, which is "good enough" for many use cases.