One of the things most new users of Mattrbld stumble over is the fact that they have to manually sync back any changes they make for them to take effect. In this article, I’d like to outline the reasons why Mattrbld requires this and why it won’t have an auto-sync feature that takes care of this step automatically.
What is Syncing in Mattrbld?
Contrary to most other content management systems, Mattrbld works on a local-first basis. The content is fully cloned to the user’s device from a central location, often referred to as a repository, during the import process and all changes happen on that local copy. These changes can then be pushed back to a central repository at a later date to make them available to others. This has several benefits, such as increased speed and offline capabilities, but comes with the caveat that the changes aren’t automatically available to everybody else.
Syncing refers to the process of publishing local changes to the central repository and pulling the latest changes that others have made from there. So actually, there are two forms of sync in Mattrbld: one to pull, one to push.
The pull sync happens whenever a project is loaded, so it can be thought of automated in that way—although it still doesn’t run periodically, if a project stays open for a long time, it is likely to be out of date. That’s why a pull sync can also be run manually and will be executed before any changes are pushed back to the central repository.
The push sync on the other hand is never executed without an explicit user action. This has several reasons.
Why it doesn’t Happen Automatically
A big part of why Mattrbld runs local-first is to reduce the fear of breaking something that a user might have. Even developers sometimes worry about making changes to a complex website, because it can be hard to judge what effects the change will have, and many content management systems have complicated and convoluted interfaces. If everything happens locally at first, nothing can happen to the public version of the website, users cannot even break anything for another user except for themselves—and in the unlikely event that they do break something for themselves, they can simply discard the local changes they made and everything will be fine.
Deliberately syncing changes back to the central repository acts as a signal telling others “these changes are ready to be shared”. Depending on how the repository is set up, these changes can then either be used to publish an updated version of the website or project the user was working on, or to kick off a review process before they become available to the public. Either way, the sync creates a fixed point in the project’s history that can even be reverted at a later point in time.
In addition to that, since many modern projects get rebuilt when changes are pushed to the central repository, every pushing sync operation has a cost associated with it. Rebuilding a project requires computing resources, which have economical and environmental costs, which both should be kept low. So instead of syncing every individual change automatically, Mattrbld gives users the power to group their changes in order to reduce re-builds. Especially in larger projects that have longer build-times, this can have a significant impact.
Mattrbld is all about giving users control over their content—on a project-basis, but also on an individual level. Adding an automatic sync option for pushing changes would take some of that control away.
Give it a Chance
While having to remember to manually sync changes once they’re ready might seem a nuisance at first, the benefits of greater control and saving resources quickly outweigh the drawback once the process has become a natural part of the workflow. Mattrbld already signals when there are local changes that haven’t been synced yet, so in the end it is a small click of a button to put a finishing touch to a day of successful content editing.