search

DmitrySharabin / mavo-firebase-firestore

Firebase backend plugin for Mavo. Store and sync app data in milliseconds. Store and serve files at Google scale. Authenticate users simply and securely. All the Google Firebase powers are at your fingertips.
https://plugins.mavo.io/plugin/firebase-firestore
MIT License
6 stars 0 forks source link

realtime mode doesn't autosave? #10

Closed karger closed 4 years ago

karger commented 4 years ago

I'm not sure this is a bug, but it seems that if you activate realtime mode, firebase will now accept push updates, but it doesn't autosave. Which might perhaps lead to some odd outcomes when your local data edits get overwritten by data pushed from the server?

DmitrySharabin commented 4 years ago

I'm not sure this is a bug, but it seems that if you activate realtime mode, firebase will now accept push updates, but it doesn't autosave.

You are right; by enabling real-time updates, we don't enable autosave. Do you think we should? I believe an end-user won't be happy if we push their raw data (that they did not intend to share) to everybody who subscribed to real-time updates of shared data only because an app author switched this feature on. I think we should leave it under an author's control. And if they really want data to be saved immediately, they can do that via the mv-autosave attribute.

Which might perhaps lead to some odd outcomes when your local data edits get overwritten by data pushed from the server?

True. That might happen. Actually, it happens exactly the way you described: as soon as new data been pushed from the server, the local data updates immediately, regardless of whether an end-user changes data or not. Unfortunately, the plugin doesn't respect a user's local data now. I know it's unacceptable, but for now, it is what it is.

I have this comment in the plugin source code.

// TODO: There's the problem of what to do when local edits conflict with pulled data

For now, I don't know what the best way to handle merge conflicts is. What do we expect? Some sort of a dialog where an end-user sees that something went wrong, and they need to decide what changes to accept: the ones they made or the ones came from the server? Or we can let a mavo author specify the desired behavior via some attribute?mv-firebase-changes? mv-firebase-changes-source? Like so: mv-firebase-changes="server" or mv-firebase-changes-source="local"?

karger commented 4 years ago

I don't have a strong opinion yet about the "right" thing to do here. I don't think we have a good merging solution. For typical currently-imagined mavo applications it isn't a big deal since there's only a single user writing, which makes write conflicts unlikely unless they're using two devices. And if you're only reading not writing it isn't a problem. Long term we may need to move to an operational-transform model of the data (like google docs) to better handle collaboration.

But since this means you have to enable both autosave=0 and mv-firebase=realtime to get bidirectional syncing, issue #11 is relatively important to resolve!

DmitrySharabin commented 4 years ago

I believe I can close it since I moved all our thoughts to a separate issue (#12).

karger commented 4 years ago

I think what tripped me up here was that for me "realtime" suggests bidirectional synchronization. I wonder if it might make sense to create a more clearly signifying keyword and use in the docs, while continuing to support both in the code for backward compatibiltiy. I'm not sure what a clearer keyword would be---"receive-realtime"? "server-push"? I don't have a great suggestion yet.

DmitrySharabin commented 4 years ago

Totally agree. We definitely need another name.