This page explores local-first software - software that keeps your data locally as much as possible and only sends it over the network for synchronization or backup.
The paper linked above defines seven ideals for local-first software. I will only be considering those that I consider important.
Most software these days is designed to be cloud-first. Data and often the application itself is served from the cloud with the user mostly dependent on thin clients like web apps. Keeping data locally is increasingly de-emphasized over keeping it in the cloud. Cloud-first software is less free from a user freedom perspective and less convenient as well.
I currently see a lot of potential in Syncthing and the SQLite database. Any application that exposes its storage as a set of files that Syncthing can sync or as a SQLite file can be potentially used as a local-first application.
Though local-first is something developers have to consider in the architecture of their applications, end-users can also take control by using their desktop and mobile applications together with synchronization solutions to have a local-first experience.
Single Writer, Multiple Readers
I once attended a meeting where the participants were writing notes into an Emacs org-mode file with auto-revert-mode enabled. The file is synced with the participants using Syncthing (using relays, there was no direct connection). We allowed only person to write to the file at a time but all could see the changes updated in their respective Emacs buffers with a lag of a second or two. I would consider this a pretty good alternative to most collaborative editing tools and it puts user freedom first. People get to use the text editor that they're most comfortable in, instead of a basic web-based editor that most collaborative editing tools have. The data is always persisted to the local disk and eventually synced irrespective of network issues. In case of a network failure, a cloud-first collaborative editing tool might either block the user from writing or fail to save data depending on the implementation. This local-first system saves the data in at least the writer's computer.
Guidelines for application developers
Note: Not all guidelines might not apply to all applications. For example, the first guideline might not apply if your application is a downloader.
- Your application should not require a network connection for its basic operation
- Think hard if your application has a really good reason to use MySQL/Postgresql instead of SQLite
- If your application's data is a set of files (including .sqlite3 files), allow the user to choose a different folder on the system for storing the files (usually a synchronized folder).
- Even if your application is built in a traditional cloud-first architecture, there is still the possibility to make your clients work offline. For example, a Diaspora client might accept a user's post and wait till it connects to the network to send the message.
- Build your clients with an offline-first mindset
- The user shouldn't have to download your application for each use
- The user experience should be similar irrespective of network connection
When your app goes offline, treat every user action that involves sending a request to the server as an event (see event-sourcing). Store this set of events on the user's device. When the app gets a network connection, send all the events to the server. The server applies these events in order and persists the final state to the database (here, the database is the equivalent of a snapshot in event-sourcing parlance).
Here is a listing of local-first software that I already use as replacements for cloud-first software.
|Cloud-first software||Local-first alternative|
|Google Docs||LibreOffice + Syncthing|
|Evernote||Emacs org-mode/BoostNote/Joplin + Syncthing|
|ToDoist||Emacs org-agenda, Orgzly + Syncthing|