Why local database should be the only source of truth for mobile application?

Question

Being mobile developer for quite some time (ios/android) I've learnt that local database is very rarely needed. Mobile application are mobile by definition, they usually serve only as clients to access some REST API and do parsing/display work. In such cases server and its database are the true and the only source of truth and mobile app felt more like a shallow mirror of what the data actually is. Once the data is fetched there is no guarantee that it's not immediately changed and still valid and up-to-date by the time we show it to user.

Whether it's news feed or list of chat messages we usually should consider them "dirty" when we visit the same screen again or even after some time. We just fetch data again and it feels not only easier than adding database layer, but also necessary to show user the most actual data.

For long I thought that making networks requests for whatever resources is totally fine since

1. Data becomes outdated really quickly nowadays (your news feed gets new news basically every few minutes; your chats, especially group chats get new messages on very random basis and in random quantities; if you try to cache some goods with their prices and available quantities, show that to user and it happens to be out of stock or with a wrong price at checkout you're in trouble!)
2. Let's not pretend it's easy and fast to implement database layer for an app. You're getting the whole range of things (and problems!) to think about, including, but not limited to schemas, mapping from OOP to SQL world (types, foreign keys, etc), migrations, multithreading, etc. All these things need quite some time to master to the level when you're comfortable around them. And I'm talking about both high level ORMs, CoreData, Realms, Room, and low level SQLite, FMDB and others. Though I should admit, high level tools actually solve many problems.
3. The cost of making network requests nowadays is so low it's basically free, everyone has fast internet connection and access to wi-fi spots (I don't even want to mention that parsing json was never a difficult task for ios/android device). We also have local http caches on devices (OKHTTP's cache, NSURLCache, cache-control), gzip, etc. The only real cost I see here is battery, but I'm not qualified enough to compare battery consumption of single network request/maintaining socket connection opened vs writing/reading to database on disk
4. In some situation where you can't get data from your api it's better to show network error than to silently show outdated data (tolerable for news feed, don't care, but definitely intolerable for taxi app where I can't tell if taxi is lagging or my app/network is lagging)

It feels like integrating a database that mirrors the server one's is a very expensive commodity in terms of development time. It feels more like a nice to have feature and that it could be done only when you have (a lot of) spare resources. It feels justified only if business actually needs it for some logical thorough reason. Or for some data that's by definition belongs to user/device and should/could not be accessible to outer world (basically server and other users). For example, recent search requests (queries, not responses), tokens, preferences, etc.

Now I'll try to cite a few resources I saw and explain my concerns about them:

• android's jetpack guide raises interesting question of what to do, if app needs the same piece of data on different screens (user in this example). If one screen updates data then another screen wouldn't know unless some coordination mechanism is involved. For that reason Room is used. But it feels much easier to implement just in-memory user cache. Not only because it's faster (at least for me, this tutorial looks promising though) but because users' data could become invalid if we close app and open it in few hours - I honestly don't see any reason to cache it, just fetch it again from server, not a big deal, right? In other words - why would I bother implementing "hard" expensive to implement database cache, if I just could save anything in in-memory cache (basically variables, lists, etc)(and possibly use reactive programming (or whatever, really) to be notified about changes). It's really hard to come up with example when I could get OOM exception because of cached users. In the end a single .png picture occupies as much memory as maybe hundreds of user objects.

• “Use a single source of truth: the database.” — Gwendal Roué. Author advices to use database as SSoT and not rely too much on objects that was just queried. Why would I bother to rely on database at all if I could just rely on my api backend in the same way?

• Should data be stored to local database in Android when heavily using REST services? Feels relatable, actually

After all said it just feels that

1. We should store only data that's immutable by definition (or changes so rarely and/or so unimportant) that we could store it once and forever and never worry about it being outdate

2. Developers are mistakenly(?) trying to rely on database as the single source of truth even though it isn't. It is merely a cache that's always potentially outdated. The only real source of truth is your server.

3. I probably missing some really huge point here. It is an unexplored territory for me and I humbly hope to hear from people who successfully use databases and could explain some unobvious (to me) benefits.

Answer 1

You need a single source of truth. Having a single source of truth that is always available is very handy.

It really makes life easier if you use an always available database as single source of truth and use the server to update the database. The network is not always available. A fast network is not always available. And lots of people do not have gazillions of mobile data per month available.

PS. A little bit of SQL is really easy to write, and SQL lite is available everywhere. If that is too hard for you, save your data as JSON. And it seems you don’t quite understand what “single source of truth” means. Data on a server is a rubbish source of truth because it can change any time without you knowing.

Answer 2

1. No it doesn't. A social media page, maybe, but even there that's not true. How often do users change their friends/following lists? Much less often I'd wager. What about the list of credit card types, VISA, MC, AmEx, which an online store (like Amazon) accepts? Do you think the cards accepted are changing daily? And its not just the card type, b/c each card type has their own way of validating what is a valid card number, and I can tell which type by the card number entered. You could store the pattern locally. But if you're going through checkout and its only available via a network call, that's an issue. Especially during checkout. Am i going to abandon my order or try again? The risk is that some people will give up immediately. Is Amazon really changing the departments which products can be linked to daily? No, they have Electronics, Groceries, etc. Sure, the products included in each can change, but the actual list of departments? Can my app function without them? There's TONS of data like that which changes very infrequently.
2. No one is saying its not difficult; but if the choice is a difficult implementation or THE APP DOESN'T WORK, what do you do? This statement of course leads into #3.
3. This is laughable, even in 1st world countries. Every network call has a certain, almost fixed, amount of overhead. Let's say its 1K of just header information. 100 calls = 100K of just header data. What if the average call returns only 0.5K of data? Now you have 150K of data for making each call independently. But if you made one call? Now its 51K of data. Of course, local storage is ALWAYS faster than a network call, and there's must less overhead getting that 50K of actually useful data. "Speed is one of the main advantages of local storage" This can also happen BTW on an employer's own network; the network response is fast and good at 6AM, where maybe only the odd employee is actually in and working at that time. But come 12PM when most are on lunch and think its OK to watch YouTube on break with personal devices on the company network, the network the becomes unusable to employee's still trying to do their job. I've personally worked at a place where this was an issue.
4. This depends on your use case. At my current job, this is not the case. If the network is unavailable/unreliable, they cannot work at all. If the data is cached, they can do their job. It could be the work item they are actively working on has a misspelling in the description; while they were offline (and thus using local data) someone fixed the misspelling. Does that mean they shouldn't be able to work at all on their task? How does the fixed spelling in the description help them perform their task? The answer in my case is it doesn't. They can still perform their task correctly even with outdated data. What about an Amazon warehouse worker? Does it matter to them if the price changed for the item they are packing into a box? No, it doesn't.

Now, your concerns.

1. Yes, if the business requirements are such that the same data can be updated on two different screens, you need to build something that handles this. This can be pretty trivial, by the way. A timestamp on the row will tell you if its changed since you loaded the data, and how you handle that will be determined not by developers, but by your business analyst. The business requirements are what matter here, and you need to be told by the business how to handle this scenario if its possible for it to occur. That it make be difficult to do is not relevant, what is relevant is that 1) the business rules allow this possibility and 2) the business must also decide how to handle it. Its their software, they are paying for it.
2. I'm not sure what you're getting at here. The business is what decides the single source of truth. This flows from my point directly above; if two people can change the same data and do so, the business decides how to break ties. You simply implement what they tell you.
3. The benefits of a local caching of data from a source of truth is performance; in some cases, it can mean the difference between your app being usable by the users or not. We are in this situation at my current job. Ideally our customers will fix their networks to be reliable/fast. But they probably won't, and will go to a competitor rather than use our app which doesn't work for them.

Answer 3

First of all, I must agree @gnasher729.

Internet is NOT cheap and available everywhere. Especially in non first world countries.

What if user want to check chat log in offline mode?

I will assume your answer is it is immutable.

So before discussing anything, You have to define why you NEED the truth?

An game validates dlc purchase?

If a user wants to play the game on airplane, would the game asking them to purchase wifi for dlc validation?

An sns app for getting feed?

For feed, if a user has limited bandwidth per month and an sns app choose to always as server for news.

What would happen if the user open this software after a year? This app might suck up user's bandwidth in less than half second.

Back to the topic, WHEN do you need the truth?

If it is an online realtime combat game, I would agree that the game has to ask server for truth.