It seems that mobile local databases with sync capabilities are gaining some momentum in the mobile scene. That kind of approach can replicate data from the backend to the app (and vice-versa) without much effort. You won't have to write all that code in the app and backend to exchange information. It sounds awesome, right?
But, I was wondering in which cases the replication won't be efficient. What are the pros and cons of that approach? I'm particularly worried about too much data consumption on the mobile side and searching for info that's not on the local database.
I would argue that the replication approach available in CouchDB, Couchbase Mobile, PouchDB…actually saves on data consumption because there is a local database on each end of the replication. Instead of storing the data in a cache that would potentially be invalidated in time, the Sync approach looks for the diffs on each side and works out what’s missing and should be sent.
However, the sync approach doesn’t fit all use cases. If we imagine the example of a location based mobile application. There may be a feature to search for content around the user’s location. It wouldn’t make sense to replicate the entire server side database to the device to make that query. You can use REST API calls for those type of queries. And once a user has "bookmarked" locations, use the sync approach to make them accessible to all logged in devices.
In the case of Couchbase Mobile, the filtered sync is handled by the Sync Function and the REST API can be used for queries on the server side database.