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
- 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!)
- 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.
- 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
- 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
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
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.
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.