> However the size of a codebase in terms of its features and components is almost always directly correlated to the numbers of bugs you're likely to find and the difficulty you'll have maintaining it.
Fully agree. In addition, I find there's also the time component. Because requirements for existing functionality change over time, both code and data become inaccurate and a mess if they are not refactored. This leads to more bugs and to less trust in the data model (e.g. when can something be null).
I've recently read the local-first article and thought this could a good solution for many apps to avoid database servers. This in turn would enable more business models using licenses (e.g. Sublime Text) instead of subscriptions.
I also believe that in the future we'll have these generic sync services you're talking about, just like today we have file syncing services. I actually believe we could start having them today and get most of the benefits of having a local-first sync service. I think we could have a relational database server (something which most devs are used to) running somewhere, paid/hosted directly by a user/company, together with a protocol implemented by a local daemon that allows apps to find that database server. This local daemon could be provided by a service (e.g. Apple Business, Syncthing) that provides group membership, so a set of users and devices could access the same database server (and corresponding database). This solution would always require internet access to be able to use the app, but that's already the normal today, and looking at how the technology is advancing (thinking Starlink, 5G), I can only see that becoming less of a problem.
For completeness, I also don't think a local-first sync service can be implemented with file syncing services + SQLite today, even if you only allow changes when online. First there are still chances of multiple people changing the database at the same time, which is not ok because file syncing services only see conflicts at the file-level and they would not be able to recover from them automatically. Finally, it'd probably also be weird to see a SQLite file in a folder somewhere in the file syncing service which could be accessed by any app that used this protocol. I would love to see SQLite being part of a local-first sync solution though.
Fully agree. In addition, I find there's also the time component. Because requirements for existing functionality change over time, both code and data become inaccurate and a mess if they are not refactored. This leads to more bugs and to less trust in the data model (e.g. when can something be null).