Local-first development stipulates that by using local resources (storage and network), and without using central servers , a user can maintain ownership and control of the data they enter into the software, be able to act on it at any time , synchronize it across multiple devices, and work on the data collaboratively with other users.
Motivation
By using central servers , especially cloud servers from other companies such as those used in collaborative tools (Google Docs, Trello, etc.), control over the data stored on said servers is ceded , since the server's status and ability to access them depend on the server.
In the case of the Illustration, user data becomes inaccessible if access to the backend servers or database is lost.
On the other hand, if the user works in isolation on their device, without using central servers, the ease of synchronizing data between multiple devices and collaborating with other users on the same data is reduced .
With local-first development, the goal is for a user to maintain control and ownership of the data entered into an application without giving up the collaborative and synchronization capabilities that these provide.
Illustration 1: Conventional architecture diagram
Architecture and features of the resulting software
In the image, we can see an example of a possible local-first architecture. As you can see, it's possible to use synchronization servers and backup storage. However, unlike common databases and backend servers, these local-first counterparts have less important functions, moving from being central to being dispensable. Doing away with them would result in an architecture consisting only of clients.
On the other hand, local-first aims for software products to be usable even when offline or with limited connectivity. However, in this scenario, there is a possibility that, while changes are being made offline, two users may act on the same piece of data (for example, the same paragraph) , and a conflict may occur when attempting to synchronize the data, making synchronization impossible or difficult. In response, the most widely used solution is the implementation of conflict-free replicated data types.
Figure 2: Diagram of a possible local-first architecture
Conflict-free replicated data types (CRDTs)
Conflict-free replicated data types, also known as CRDTs, are data structures that are replicated across multiple devices on a network. These replicas can be updated independently, concurrently, and without coordination with other replicas. Afterward, when synchronization is attempted, an algorithm automatically resolves any inconsistencies that may occur, so they eventually converge to a common state.
All divergent replicas can be synchronized in any order by any machine that hosts a replica, and once all machines have seen all copies, they are guaranteed to converge and reach the same state. This is important to eliminate the need for a central server to coordinate convergence.
CRDTs can be classified into two different strategies depending on the method followed to obtain consistency: state-based CRDTs and operation-based CRDTs.
State-based CRDTs involve sending the state of data replicas between different devices and combining their states until the final state is reached.
Figure 3: State-based CRDT diagram
On the other hand, operation-based CRDTs, instead of sending the general status of the replica, send the operations performed on them, updating the other replicas.
Figure 4: Operation-based CRDT diagram
It may not be necessary to implement CRDTs, as there are tools such as libraries or frameworks that already implement them. Some examples of these tools are Yjs, Automerge, and Replicache.
State of the art
Although local first development is a concept that has been around for several years, it has only recently begun to increase in popularity, mainly due to the rise of cloud tools and their potential drawbacks, discussed above.
However, despite this increase in popularity, there is still little documentation on projects built based on local-first principles.
Conclusions
Server-based tools are widely used today in many different contexts. They are very useful and powerful tools, but, as mentioned above, they also have their drawbacks. For this reason, it's important to analyze these drawbacks and take them into account when storing data in them.
Local-first software can be an alternative to server-based collaborative tools, allowing you to achieve some of their benefits without relinquishing control over the data created in the software. However, local-first software development can be complex, with potential pitfalls such as the use of a different architecture and the addition of CRDTs.
Want to know more about Hunters?
Being a Hunter means accepting the challenge of testing new solutions that deliver differentiated results. Join the Hunters program and become part of a cross-functional group capable of generating and transferring knowledge.
Get ahead of the digital solutions that will drive our growth. Learn more about Hunters .
