Sync automatically takes care of generating API calls, creating transactions, applying them on the backend, handling conflicts and errors, reverting erroneous changes, rebasing in-fight changes, and offline capabilities.
When we started work on
@linear
, we felt real-time sync was a core functionality we had to invest in from the get-go. It turns out sync was important, but not for the reasons we thought. Read on.
Our gut feeling was that real-time updates were required from a modern tool like Linear. Who wants to refresh to see the latest data? But how often do you find yourself in a situation where multiple people update data simultaneously in a project management tool?
Not that often, it turned out. Aside from special cases where your team gets together to operate on data - like planning your next cycle - edits are made across the entire dataset, with the same data being touched at the same time relatively infrequently.
Don’t get me wrong, we still believe that real-time sync is essential, but there are two more valuable things we got out of real-time sync that we did not appropriately anticipate: **App speed** and **Ship speed**.
The most straightforward way to implement real-time sync is to load the entire app state and then keep it up-to-date with real-time changes. While we’ve had to add complexity to this simple initial implementation to support larger workspaces, the core tenant still holds.
Clients have the vast majority of their workspace data stored locally. Hence page loads are all but eliminated. As a result, startup times are fast, filters work instantly, and there are no page loads.
But arguably even more essential and surprising was that real-time sync helped us ship new functionality much faster than regular architectures. How? By eliminating a vast swathe of complex and error-prone code.
To create a new feature as an engineer, you essentially render and modify local in-memory data structures to build new functionality. All the complexity that comes with requests, conflicts, network errors and retries are handled by sync for free.
All UI code automatically re-renders when the data that they accessed updates. Whether the data changes come from the user or the network doesn't matter. So you get multi-player for free, too.
As you can imagine, reducing the number of layers engineers have to work on dramatically improves the speed at which we can ship new functionality. After experiencing this architecture at scale, I'm spoiled for life.