Cache-First vs Network-First Loading

[00:00:00]
>> So far we have an index DV database. And we know it's the content of that database is being served using cache first, but that's not the only algorithm available. So if you continue to the next chapter here, so I have already a code that is network first.

[00:00:22]
So let me replace. I will load or just add another version so I can just come back here to my code to main ujs and these let's call this load cache first I'm going to add another load or just paste the one that I have. And let's try to analyze this algorithm, so I'm opening database that's okay and then trying to fetch from the network always as the first action, okay?

[00:00:54]
And I'm filling the menu with what comes from the network, as before, but what if the fetch cannot be done? For example, the server is down, the JSON that is returning from the server is invalid, or we don't have connection? It will fail, the promise will be rejected, and because I'm using a wait, I can use try catch.

[00:01:23]
So if I catch an error, it's because, yeah, it's not working. Getting the data from the server is not working. Well, now let's go to the database, only if the network failed. But also we need something else. Every time we are getting successfully the data from the server we can also update the cache at that moment so we clear.

[00:01:54]
Clear will actually delete all the data in the data store and I'm updating my database, so this is the scenario again, we open the app we try to get the menu from the server first. If it works, okay, we update the cache for the future, and we serve from the network.

[00:02:18]
If we open the PWA without connection, when we try to fetch, it's not going to work, so then we use as a fall back, the index DB database that was updated the last time that we could fetch, make sense? It's just an algorithm, so not nothing new from an API point of view.

[00:02:41]
It is just reordering the logic of what you're doing. And you can create your own algorithm here. There are more ideas, okay? It's up to you make a decision of how do you want to update the data, when, If you prefer fresh data or if you prefer fast data, it's your decision.

[00:03:07]
Any question, you have any question? We have something.
>> Yeah, this might be something that you have to troubleshoot, but someone in the chat says, Indexed DB object store is not dynamically updating on my Chrome DevTools and not showing the latest data. I'm manually using the refresh database option to the latest data.

[00:03:29]
>> Yeah, yeah That's correct. So on most of DevTools, not just Chromium, on most of DevTools you have to manually refresh the data because from a performance point of view, also from an event point of view. So even DevTools doesn't know when you are changing the database or the data, so you actually need your re-querry, and that's the refresh button.

[00:03:55]
And by the way, if we try this on Safari or Firefox, you will find the same issue there and here on Safari, and if I inspect this and they open store catche, I have my Index DB database here as well. And we also have the refresh button here, but the order is empty right now.

[00:04:13]
So on every web tools on browser, you will find the refresh button. So you will need to manually refresh the data. Well, actually With that, most of the Indexed DB basic behavior was already covered. So what's next or what you can continue reading about, but using the library is actually pretty simple, transactions.

[00:04:36]
Again transaction is a way to execute more than one operation under one transaction. It's actually not a big deal. Cursors, in case instead of getting all the values, I can go and read one by one. So if you have 1000 objects, it will be much faster to read one by one that get in all the objects in memory at once, okay?

[00:05:02]
So that's possible. Filters for cursor, It's not like really complex but you can actually say, hey, I want elements starting with the letter A, or something like that. You cannot make really complex queries but there are some things you can do and things around performance like measuring performance on every browser, how to measure performance so then you can start playing with different techniques, techniques to actually make queries.

[00:05:34]
But with what we've covered so far, you will be good for 95% of the use cases of Indexed DB, actually.