Local-First development
Our technology trend Hunters are as relentless as ever. This latest edition of Inspiring Technology is about local-first development, which refers to a set of principles when creating software products. Read on!
In local-first development, you use local resources (storage and network) instead of central servers. This way, users retain ownership and control of the data they input into the software and are able to use it at any time, synchronise it between various devices and work on the data collaboratively with other users.
Why local-first
When you use central servers, especially cloud servers hosting collaborative tools developed by other companies (Google Docs, Trello, etc.), you relinquish control over the data stored on these servers, since you depend on their status to be able to access it.
As shown in the image below, user data will no longer be accessible if access to the backend servers or the database is lost.
On the other hand, if the user works solely on their device without relying on central servers, it becomes harder to synchronise data across multiple devices and to collaborate with other users using shared data.
With local-first development, users can maintain control and ownership of the data fed into an app without giving up collaborative and synchronisation capabilities.
Image 1: Conventional architecture
Architecture and features of local-first software
The image below shows an example of a local-first architecture. As we can see, it offers the option of using synchronisation and backup storage servers. However, unlike common databases and backend servers, these local-first alternatives have less important functions that are no longer central but dispensable. Without them we would have an architecture made up only of clients.
Moreover, the local-first approach aims to make software products usable even offline or with limited connection. However, when making changes offline, two users might edit the same piece of data (e.g. the same paragraph), in which case a conflict can occur when trying to synchronise the data. This makes synchronisation difficult or even impossible. The most widespread solution to this issue is using conflict-free replicated data types.
Image 2: Example of a 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 in a network. These mirrors can be updated independently, concurrently and without coordination with other mirrors. So, when synchronisation is attempted, an algorithm automatically resolves any inconsistencies, so they eventually converge to a common state.
All divergent replicas can be synchronised in any order by any device containing a replica and, once all devices have seen all copies, all are guaranteed to converge and reach the same final state. This way you don’t need 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.
In state-based CRDTs, the state of data replicas are sent between different devices and these states are combined until the final state is reached.
Image 3: State-based CRDT
On the other hand, in operation-based CRDTs, replicas send update operations to the other replicas instead of sending their full state.
Image 4: Operation-based CRDT
It may not be necessary to implement CRDTs from scratch, as there are implementation tools that act as libraries or frameworks, like Yjs, Automerge or Replicache.
State of the art
Although local-first development is a concept that has been around for several years, it has grown in popularity only recently, mainly due to the rise of cloud tools and their potential drawbacks, which we discussed above.
However, despite this increased popularity, there is still little documentation of projects based on local-first principles.
Conclusions
Server-based tools are now widely used in many different contexts. These are very useful and powerful tools but, as mentioned, they also have drawbacks. For this reason, it’s important to analyse the drawbacks and take them into account when inputting data.
Local-first software can be an alternative to server-based collaborative tools, offering some of their benefits without giving up control over the data created in the software products. However, local-first software development can be a complex task, with possible difficulties such having to use a different architecture and implement CRDTs.
Want to know more about Hunters?
A Hunter rises to the challenge of trying out new solutions, delivering results that make a difference. Join the Hunters programme and become part of a diverse group that generates and transfers knowledge.
Anticipate the digital solutions that will help us grow. Learn more about Hunters.