Picking up where I left off in Part 1, I’m continuing my journey in the Grow with Google Challenge Scholarship for 2018. Last time I learned how to use a service worker to cache simple data in the example app, but this part of the lesson taught me how to properly cache and serve page resources like photos via IndexedDB.
When I started this section, I was admittedly intimidated. IndexedDB, or IDB for short, has a notorious reputation on the web for being difficult to code, even more difficult to debug, and reliant on a strange event system that almost emulates promises. In its natural form it produces spaghetti code, and Jake (the instructor) was hesistant to start down that path. Instead, he introduced us to his own version of IDB, one that uses promises. Now all of the logic of IDB can be handled by promises, which produces cleaner code.
IndexedDB is a web database supported by most browsers. It’s a little different than relational databases. Databases contain object stores, which represent value types to be stored, and within those are the individual items. Items can have keys, or one of their properties can be a key, but this represents the unique way of referencing that item within the object store. Any changes to items within the database are done via a transaction, which is an asynchronous operation on the database. In a transaction, all operations must succeed, or none of them will. This prevents the database from getting into an inoperable state via an incomplete transaction. Items within an object store can also be sorted by index, which is a different view of the same data sorted by an indicated property.
Using this database, I worked through the lesson components to store the application “tweets” called “wittrs” and extract their photo data for the cache. Why would we want to store this data in the browser? After all, it’s a server resource, right? What if the image changes? This meant we needed to implement caching while still querying the server on some occasions, to fetch new data on parameters we set, and when the network would support it. Because you can never trust the user’s connectivity, it’s always best to prepare for the worst case scenario: offline. By saving the website content in the browser via a database, it can be called later by the service worker when the page makes server requests for that content. If it’s in the cache, the page will pull it from the browser before asking the server, which means the page will load instantly with content, regardless of connectivity.
I’m eager to start using the IDB Promised library in my own projects alongside service workers. By using them together, you can use modern web capabilities to deliver an app-like experience to users.
Now that I’ve finished the first part of the program (Udacity’s free Offline Web Applications course), I’m moving on to Udacity’s free ES6 - JavaScript Improved course. This rounds out the final leg of the scholarship track by covering new features of the JavaScript language.
If you’re interested in learning more about IDB, check out the resources below! I’ll report back soon with my new findings as I learn more about Harmony, or ES6, or ES2015, or whatever you want to call it!
Resources
MDN: IndexedDB API
IDB Promised: Jake Archibald’s IDB with Promises
Google Progressive Web Apps Training: Working with IndexedDB
Udacity/Google: Offline Web Applications