Local-First Software

How does PowerSync fit in to the local-first software movement?

What is local-first software?

The vision of local-first

Local-first software is a term coined by the research lab Ink & Switch in its 2019 manifesto essay.

Ink & Switch's rationale for local-first is to get the best of both worlds of stand-alone desktop apps (so-called “old-fashioned” software) and cloud software:

“We would like both the convenient cross-device access and real-time collaboration provided by cloud apps, and also the personal ownership of your own data embodied by ‘old-fashioned’ software”.

The manifesto proceeds to defines local-first as software that:

“prioritizes the use of local storage (the disk built into your computer) and local networks (such as your home WiFi) over servers in remote data centers”.

It also puts emphasis on the primacy of the local copy of data:

“In local-first applications [...] we treat the copy of the data on your local device [...] as the primary copy. Servers still exist, but they hold secondary copies of your data in order to assist with access from multiple devices.”

Expanding on this, the manifesto identifies 7 ideals “to strive for in local-first software”, which we will explore further below.

Much more theoretical research is still needed to practically build software that conforms to all of the ideals of local-first software as envisioned by Ink & Switch, since it will need a fully decentralized architecture and needs many complex requirements to be addressed (see here for more details). In the meantime, the manifesto essay does provide practical guidance on things that developers can do to bring their software closer to the ideals.

Local-first in practice today

Most implementations that are referred to as "local-first" today conform to only a subset of the local-first ideals envisioned by Ink & Switch. We argue that a practical definition of most local-first implementations today is the following:

Local-first implementation today generally refers to apps that work with a local client database which syncs automatically with a backend database in the background. All reads and writes go to the local database first.

This kind of architecture already enables large benefits for both end-users (speed, network resilience, real-time collaboration, offline usage) as well for developers (reduced backend complexity, simplified state management, etc.). Refer to References for more on this.

Does PowerSync allow building local-first software?

High-level concepts

Here's how building software with PowerSync as its sync engine stacks up in terms of the high-level definitions of local-first software mentioned above:

Local-First Concept / Definition	Does PowerSync Enable This?
Software that prioritizes the use of local storage. All reads and writes go to the local database first.	Yes. PowerSync allows developers to build software that uses a local database for reads and writes.
Software that treats the data on the user's local device as the primary copy of the data.	Yes, generally. PowerSync allows the developer to treat the data in the local end-user's database as the primary copy of the data. PowerSync does use a server-authoritative architecture where the server can resolve conflicts and all clients then update to match the server state. But the client will not update its local state to the server state until all pending client changes have been processed by the server.
Software with a decentralized architecture, which allows the software "to outlive any backend services managed by their vendors"	No. PowerSync does not use a decentralized architecture. PowerSync uses a server-authoritative architecture. However, there are ways to ensure a degree of longevity of software built using PowerSync (see below).

Local-First Concept / Definition

Does PowerSync Enable This?

Software that prioritizes the use of local storage. All reads and writes go to the local database first.

Yes. PowerSync allows developers to build software that uses a local database for reads and writes.

Software that treats the data on the user's local device as the primary copy of the data.

Yes, generally. PowerSync allows the developer to treat the data in the local end-user's database as the primary copy of the data. PowerSync does use a server-authoritative architecture where the server can resolve conflicts and all clients then update to match the server state. But the client will not update its local state to the server state until all pending client changes have been processed by the server.

Software with a decentralized architecture, which allows the software "to outlive any backend services managed by their vendors"

No. PowerSync does not use a decentralized architecture. PowerSync uses a server-authoritative architecture. However, there are ways to ensure a degree of longevity of software built using PowerSync (see below).

The 7 ideals of local-first

Here's how applications built using PowerSync can be brought closer to the 7 ideals of local-first in the Ink & Switch manifesto essay:

7 Ideals of Local-First	PowerSync Perspective
Fast: By accessing data locally, the software should be able to respond near-instantaneously to user input	PowerSync inherently provides this: All reads and writes use a local SQLite database, resulting in near-zero latency for accessing data.
Multi-Device: Data should be synchronized across all of the devices on which a user does their work.	PowerSync automatically syncs data to different user devices.
Offline: The user should be able to read and write their data anytime, even while offline.	PowerSync allows for offline usage of applications for arbitrarily long periods of time. Developers can also optionally create apps as offline-only and turn on syncing of data when it suits them, including on a per-user basis. When syncing is configured, data is synced to users based on the Sync Rules configuration for offline access. Mutations to data while the user is offline are placed in an upload queue and periodically attempted to be uploaded when connectivity is available (this is automatically managed by the PowerSync client SDK).
Collaboration: The ideal is to support real-time collaboration that is on par with the best cloud apps today.	PowerSync allows building collaborative applications either with custom conflict resolution, or using CRDT data structures stored as blob data for fine-grained collaboration.
Longevity: Work the user did with the software should continue to be accessible indefinitely, even after the company that produced the software is gone.	PowerSync relies on open-source and source-available software, meaning that the end-user can self-host Postgres (open-source) and the PowerSync Service (source-available) should they wish to continue using PowerSync to sync data after the software producer shuts down backend services. There is also an onus on the software developer to ensure longevity, such as allowing exporting of data and avoiding reliance on other proprietary backend services.
Privacy: The software should use end-to-end encryption so that servers that store a copy of users’ files only hold encrypted data that they cannot read.	For details on end-to-end encryption with PowerSync, refer to our Encryption section.
User Control: No company should be able to restrict what a user is allowed to do with the software.	In theory, the server-authoritative architecture of PowerSync allows the vendor's backend to override the user's local data (once all pending changes by the user have been processed by the server). However, this is ultimately in the control over the developer.

7 Ideals of Local-First

PowerSync Perspective

Fast: By accessing data locally, the software should be able to respond near-instantaneously to user input

PowerSync inherently provides this: All reads and writes use a local SQLite database, resulting in near-zero latency for accessing data.

Multi-Device: Data should be synchronized across all of the devices on which a user does their work.

PowerSync automatically syncs data to different user devices.

Offline: The user should be able to read and write their data anytime, even while offline.

PowerSync allows for offline usage of applications for arbitrarily long periods of time. Developers can also optionally create apps as offline-only and turn on syncing of data when it suits them, including on a per-user basis.

When syncing is configured, data is synced to users based on the Sync Rules configuration for offline access. Mutations to data while the user is offline are placed in an upload queue and periodically attempted to be uploaded when connectivity is available (this is automatically managed by the PowerSync client SDK).

Collaboration: The ideal is to support real-time collaboration that is on par with the best cloud apps today.

PowerSync allows building collaborative applications either with custom conflict resolution, or using CRDT data structures stored as blob data for fine-grained collaboration.

Longevity: Work the user did with the software should continue to be accessible indefinitely, even after the company that produced the software is gone.

PowerSync relies on open-source and source-available software, meaning that the end-user can self-host Postgres (open-source) and the PowerSync Service (source-available) should they wish to continue using PowerSync to sync data after the software producer shuts down backend services.

There is also an onus on the software developer to ensure longevity, such as allowing exporting of data and avoiding reliance on other proprietary backend services.

Privacy: The software should use end-to-end encryption so that servers that store a copy of users’ files only hold encrypted data that they cannot read.

For details on end-to-end encryption with PowerSync, refer to our Encryption section.

User Control: No company should be able to restrict what a user is allowed to do with the software.

In theory, the server-authoritative architecture of PowerSync allows the vendor's backend to override the user's local data (once all pending changes by the user have been processed by the server). However, this is ultimately in the control over the developer.

References

PreviousDemo Apps / Example Projects NextUsage & Billing

Last updated 3 months ago