Hoodie: very fast web app development

If I'm writing an email in the Gmail app on Android, what I want when I hit send is for the app to save the email locally, and then do its best to try and deliver it. Ditto for, basically, every other app on the phone that talks to a remote server. If I try and send a tweet, I want it to go "sure", and then be able to go on about my business while it works in the background. (And, again, that's how the actual twitter app works.)

And if I'm using some app that lets me take notes about a meeting or interview and syncs them with the cloud, I sure as HELL want to be able to take those notes and save them locally, even if the cloud sync had to be delayed. "Sorry Mr. CEO, but I can't seem to get wifi in this meeting room. Can we go out on the balcony and you just run back over those last few points?"

Now, yeah, I need some way of checking to see if it has actually sent the email or whatever. And if it fails, a notification that it has done so is not amiss. Mobile apps, typically, already do this sort of thing. (For gmail for android, you can check the outbox to look for unsent emails, and I believe twitter for android will notify you if it fails to send a tweet.)

To the extent that you're just saying that the app needs to have a UI which doesn't lie or surprise the user, then I agree wholeheartedly. If the user cares whether or not the cloud has been updated, or the message has actually been sent, don't lie and claim it has when it hasn't!

But if you're saying that as a general rule we need to not handle network sync stuff in the background, I think that's nuts. Nobody wants to sit there with an email draft open hitting send every so often to see if the 3G signal is good enough to talk to the mail server yet. Nor do we want to save a bunch of emails as drafts when offline, then have to go open each one when we get net access again and send them. (Come to that, in your model, could we even save an email as a draft in gmail without net access? Remember, the drafts folder is synced. Do we want the app to claim that a draft has been saved when it's not accessible from your desktop gmail client? Isn't that another case of "pretending we've saved a draft when it's not really saved"? If not, why not?)

TL;DR: Good UI that doesn't lie to the user is important. That's not a good reason to cripple your apps functionality so it doesn't do anything you can lie about.

another way to think about this (from the old days) is that disconnected mode data is a given because the rate of growth of data is far greater than the rate of growth of bandwidth. So everyone can't always be accessing all their data in the cloud through an always on infinite bandwidth connection.

So you're going to need to carry a subset of your data with you - the subset that's "hot".

Now having said that keeping hot data in sync with the larger data store is a hard problem - p2p or not.

And what these architectures (CouchDB, PouchDB, ...) do is take the sync problem and make it an infrastructure issue so it only has to be solved once by the infrastructure creator (CouchDB team) rather than again and again and again by each app developer who wakes up in the middle of the night and realizes they have to solve "sync" in their app as an application problem. Then they have a nightmare and when they wake up they are babbling.

The additional anti-pattern-badness with sync-in-the-app is that that kind of sync is usually incompatible with another app's bespoke sync. But when sync is in the infrastructure then a much larger group of people who use that infrastructure can share data across apps if they want to without having necessarily to share a schema. This is the real power of making sync part of the underlying computing fabric.

Finally when this infrastructure is open source the real -danger of lock-in such as when you use Dropbox is mitigated, should you want to have that freedom.

Cheers.