Keep your CRUD off the Internet

With everything going mobile, and mobile not being so well connected, i'm looking at writing to local mobile storage, and then later syncing that storage to the server, when a connection is available.

This is perfect timing for me.

Thx.

Aside from being an advertisement, this does make a reasonably decent point for some use cases... though I don't believe most of them are ones that are commonly solved with web-based CRUD.

However, letting people do these things offline on mobile devices introduces non-trivial problems of its own.

You've now turned your presumably-consistent, probably-IT-department-managed central database into, at best, a hub that's only eventually consistent. Someone's on vacation and made some updates on their phone? Sure, it looks like it was applied. Better hope they get back in cell range or on a network again for long enough to update -- and that they have a way to monitor it and ensure it was successful -- and at this point you're losing at least part of the convenience this was supposed to enable.

You've also now created the necessity for more robust conflict resolution. When you get two people editing the same data in a live web form, you can at least invalidate the second person's update if you're keeping last-updated timestamps. This approach falls on its face in an edit-offline-then-upload model because you now either have to automatically merge changes (yikes), re-create deleted records that were edited (and deal with dead references, yikes), or implement a prompt to get the user to resolve it themselves (unhappy user and yikes).

Of course, you also have to decide who should get how much and which of your data synced, make sure it's secure, and supply some mechanism so that a careless user can't drop his phone while not locked and allow someone remote access. Making sure the data is irretrievable without the phone being unlocked and the user signed in to the app is the least of your worries, but still something to worry about. Plus you have the potential for sensitive user data being distributed to places it shouldn't be, e.g. PCI compliance issues...

I'm sure there are other issues here, but this is not a replacement; with just these issues it's a totally different paradigm. That doesn't mean it's a bad idea, but it definitely will not drop in nicely and take all that awful CRUD out of our internets.

I disagree. This surely depends on the type of crud application you're trying to build. We have a few in house business apps here, REST API and a JS frontend in the browser. Works fine, and since all our operations are atomic everything that doesn't come back with a 200 OK is fairly easy and generic to handle. The system also wouldn't be really usefull if the data weren't always up to date.

I get the point OP is trying to make but it really depends on what you are trying to build.

I'm looking for some articles about how to do syncing 101 by the way , i heard it's kind of hard. If anyone has good links about the subject ( on HTML5 offline/online sync db server ) , it would be great.

Developers used to be afraid of automatic merging and conflict resolution in version control tools. We evolved.

Many of those techniques also apply to merging and conflict resolution of database stuff. In fact, from a certain perspective, the screw cases are a bit easier.

http://zumero.com/docs/zumero_core.html#chapter_conflicts