I’m working on an app that would benefit from a file sync functionality similar to Dropbox/Box/etc. Sync is important for this idea to work, but also seems like a solved problem, so I would prefer to not have to implement it myself. However I don’t think there are APIs provided by these services that let you sync to your own backend. Dropbox deprecated their sync API a few years ago, presumably because it gave away their core functionality.
Some options that I see so far: - Use Dropbox API webhooks to be notified of file changes, then do the syncing logic myself (using s3 for persistence and postgres for file metadata) - Write my own custom sync logic for all platforms that I want to support - Try to shoe horn an open source sync lib onto the platforms I want to support (or something like git + some custom stuff). Eg Syncthing is written in Go which could theoretically get running in iOS
For option 1 my concern is that I still have to write plenty of sync logic server side, why not go the extra step and implement the client(s). I am also beholden your the API in a few ways: 1) They could end their service, 2) All my users have to have an account with them, 3) My cache of files is a bit of a 3rd class citizen as it will be last to get change notifications.
My concern with option two (write it myself) is simply that it’s a lot of work. Although it would be fun work to do, it’s still a distraction from everything else core to my service.
Option 3 seems doable but potentially a misadventure of working against the grain of the library (assuming I can find one to rework to my needs)
For option 1 my concern is that I still have to write plenty of sync logic server side, why not go the extra step and implement the client(s). I am also beholden your the API in a few ways: 1) They could end their service, 2) All my users have to have an account with them, 3) My cache of files is a bit of a 3rd class citizen as it will be last to get change notifications.
My concern with option two (write it myself) is simply that it’s a lot of work. Although it would be fun work to do, it’s still a distraction from everything else core to my service.
Option 3 seems doable but potentially a misadventure of working against the grain of the library (assuming I can find one to rework to my needs)