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.<p>However, letting people do these things offline on mobile devices introduces non-trivial problems of its own.<p>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.<p>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).<p>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...<p>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.
For apps that read a lot more than they write, there exist ACID databases in which reads don't have to touch network, while retaining consistent writes. Datomic is one; for those who have never studied datomic, the database storage is immutable in the same way that Git commits are immutable, which enables a lot of git-like things in your database, like queries without network. That way your apps can be fast without giving up ACID.<p>I don't know if anything like Datomic exists on mobile; and OP is talking about mobile apps not webapps; so OP may be kind of correct, at least today.
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.<p>This is perfect timing for me.<p>Thx.
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.<p>I get the point OP is trying to make but it really depends on what you are trying to build.
It seems to me that sync is the last mile for a great write once deploy everywhere (Mobile + Web apps) framework.<p>What I really want is a meta framework that runs rails/django for backend + angular/ember for frontend + cordova/phonegap for mobile + responsive display with HTML/JS/CSS + something for syncing to allow offline mobile. Ideally this would be loosely coupled so you could choose your components (i.e. write a native mobile app if you want, or do the backend with Go, etc.)<p>The two pieces still missing are the sync component and the glue that keeps you from having to define the same thing multiple times. Unless there's something open source I'm unaware of.
How is this going to sync just a slice of the database rather than everything in a given table? I would only want to publish one subset rather than all rows?
Like others have stated, I think it depends. Look at your target market. If the market is the USA, mobile connections are getting more reliable and really fast (LTE) and this isn't much of a problem.<p>OP should market this to devs focusing on countries where mobile networks stink.