3 ms·
Once upon a time, this is how applications worked and this was a pretty good experience. Now, you'll introduce a huge amount of user frustration around why the
by hx8 3y ago
Once upon a time, this is how applications worked and this was a pretty good experience.
Now, you'll introduce a huge amount of user frustration around why their changes never made it to the central database. If you have users closing a form, especially if it's on a webpage, they are going to expect the write to happen at the same time the form closes. Making a bunch of changes and batching them in a single sync is going to be confusing to a ton of users.
- hamandcheese 3y agoWhat happens if two users want to make changes at the same time? What if their changes conflict? How do you even detect conflicts?
- Ambolia 3y agoIt could be done with "select for update" and etags+triggers checking the etag received + triggers generating a new etag on every create/update.
- mrbadguy 3y agoIf everyone's working on their own local copy of the database then the select for update isn't going to do anything. The issue is later syncing and detecting conflicts. It's actually easier to do this with a centralized DB, hence why everything works this way. If an app is mostly offline then, yeah, ship it with a SQLite DB and life will be good, but for something like a hotel booking app that doesn't actually solve many problems and makes existing ones harder.