4 ms·
I develop an app like this (https://actualbudget.com/ https://actualbudget.com/) and I'll give you my reasons. Those kinds of syncing work will files, and trea
by jlongster 7y ago
I develop an app like this (https://actualbudget.com/ https://actualbudget.com/) and I'll give you my reasons.
Those kinds of syncing work will files, and treat each individual file as a blob. Apps don't work this way. Apps need databases and fine-grained change tracking. You absolutely don't want to make a change in two places on two separate devices and then have a sync conflict. If you throw the sqlite db file on dropbox, that's exactly what will happen.
You could try to build your app around files, but now you are rebuilding a database (and not a good one).
There are a few services that offer syncing more appropriate for apps, like Apple's CloudKit (I think that's the one?). These could work, but in Apple's case you can only run your your app on macOS/iOS.
There are a few generic syncing layers like PouchDB, and there are tradeoffs with all of those. Some of these tradeoffs are deal breakers. (there aren't a ton of good options yet)
But there are good reasons why you an app can't just eschew syncing onto the user, and assume they'll find a good syncing service. It needs to be tightly integrated with how the database works.
- yoz-y 7y agoThose are all good reasons but I’d argue that starting from the desire to be able to use existing sync services and building on that may be more user friendly. Yes you essentially need to rebuild a database, but this is for example what 1Password did.
- jlongster 7y agoI disagree. I mean, it depends on the kind of app. The data requirements of some apps might do well in a simpler model that can work OK with existing syncing services. But the majority of apps need more complex needs and you definitely should not go and build a new database. The user experience will end up being flaky (syncing problems) and/or slow (the database is not good). Not to mention that now in addition to setting up the app, the user now needs to go sign up for one of those services if they haven't already. With integrated syncing, the user just fires up the app and syncing works and they never have to care about how it works. There's a reason a whole field of research exists into things like CRDTs. Distributed apps are not trivial, and only ones with simple data needs could get by without a more rigorous approach.
- rpdillon 7y agoI generally agree with your reasoning, but recently experienced a counter-example myself. I recently picked up Joplin for note-taking, and the fact that it can sync reliably through my NextCloud instance via WebDAV was the deciding factor in me sticking with it. If I had to rely on a company to stick around to sync my notes, or I had to run a custom backend, I would have simply moved on. As is, Joplin is pretty close to an ideal note-taking system for me.
- jlongster 7y agoThat's awesome, there's definitely room for apps like that. I have nothing against them, but there are tradeoffs. Seems like that could work well for that kind of app.
- wolfhumble 7y agoIf you don't mind, what type of database does 'Actualbudget' use? Thx!
- jlongster 7y agoInternally it just uses sqlite, and there's a syncing layer on top of it. I gave a talk about it here: https://www.dotconferences.com/2019/12/james-long-crdts-for-mortals https://www.dotconferences.com/2019/12/james-long-crdts-for-...
- wolfhumble 7y agoOkay, thanks! :-)
- vbezhenar 7y agoYou keep local copy of database and cloud copy of database. When cloud copy changes, you detect difference and apply it to your local copy, resolving conflicts if necessary, then copy your local copy back to cloud. It might be more difficult to implement, but it allows user to use any sync option.