Keep your CRUD off the Internet

Whenever I explain database sync for mobile, somebody asks, "What kinds of apps would benefit from that?"

The correct answer is: "ALL apps".

Actually, that's an exaggeration. I see no reason for my alarm clock or calculator apps to sync data with a server. Let me rephrase:

Sync is the best architecture
for apps where a database and a server are involved

CRUD over REST is an Anti-Pattern

Many apps today keep the data only on the server and access it using REST. This approach has some big negative consequences:

  • Performance: Your app is less responsive.

    A round-trip from a mobile device to a server takes a LONG time. Under good network conditions, it could be a quarter of a second. That's enough time for the user to perceive a lag.

    Sometimes the round-trip will take longer, more like a full second, or more. That's an eternity, a one-star review in the App Store.

    Numerous studies show that when it comes to the responsiveness of a user interface, fractions of a second matter a LOT. And people don't necessarily complain about your app. They just stop using it.

    If you're going to make a round-trip to the server in response to a user action, your app is going to feel sluggish.

  • Reliability: Your app doesn't work offline.

    WiFi is great, but not everything is a coffee shop.

    Cellular data networks have dead spots, sometimes in surprising places. Even in areas with solid 3G or LTE coverage, the latency varies wildly.

    If your app is going to stop working when the wireless network is unavailable or unreliable, then your app is going to stop working a lot.

  • Complexity: Your app's code has to deal with networking issues everywhere.

    People wrap their REST calls in pretty wrappers to make them look like networking is not involved. But it is. A robust app needs to deal with all the things that can go wrong.

    If you're going to do all your basic database operations over a REST API, all your code is networking code.

The real question is "What kinds of apps would benefit from having user interaction dependent on a wireless network with inconsistent coverage and random latency spikes?"

Your app does lots of basic database operations which are often referred to as CRUD (Create, Read, Update, Delete). These operations do not want to happen over a network. They want to happen in a database which is local, on the mobile device.

And so you need sync. In the background (so the user doesn't have to wait on it). With automatic conflict resolution.

And that's hard.

Solutions that make sync easy

Do you like SQL? If so, I invite you to look at Zumero, our database sync platform based on SQLite, the relational database software preinstalled on over a billion mobile devices.

Do you prefer NoSQL? Then I'm sure our worthy competitors over at Couchbase would be happy for you to look at Couchbase Lite.

Either way, keep your CRUD off the Internet.