Database, Performance, & Serverless

[00:00:00]
>> We covered the four APIs, okay? The last thing that I have for you is just a set of best practices, ideas, things that you should follow after this course. So first, in terms of database and performance, it's always better to store small objects. So remember the case that we mentioned before of storing a redux state, a large redux state, that's a bad idea.

[00:00:28]
So it's always better to store smaller objects because of the cloning, and also because of the performance of the database itself, and also because there is no way to get a slice of an object from IndexedDB. The only way if the object is in a slice beforehand, okay?

[00:00:50]
So that's why you should store smaller objects in the database. Remember to use Web Workers or Service Worker even if the IndexedDB API is asynchronous, okay? The worker will help you also to increase UX. And remember that you can create custom indices or indexes for faster access or collections of objects for keys that you wanna search later.

[00:01:23]
But also, don't abuse the generation of indexes, because they are going to harm performance. Okay, this is always a problem in databases to find the balance between, mostly if you have thousands or millions of options, okay? For ten objects, not going to make any difference. So serverless ideas, okay, what's that?

[00:01:50]
So the data that we have in our local storages lives locally on the device, and we know they may disappear anytime. So yeah, you can sync to the server. We know how to do that kind of, okay, in the cloud, that's fine. But there are other ideas that some web apps are taking mostly in, let's say, the federated space.

[00:02:16]
Even, we can call it the Web3 space, where let's own the data, let's make the user owns the data, okay? So you can export your data, your IndexedDB to a file system. So offer the user a way to export the data to the file system. Take the IndexedDB.

[00:02:35]
Cache storage, maybe you don't need that because it's a cache at the end, okay? But IndexedDB, well, let's export IndexedDB to the file system, okay? So you can import that in another system, in another device, you can backup that, okay? So offer the user that option. Export and import through QR codes, I mean, the size is limited here, but I've seen a couple of options.

[00:03:03]
So you can generate client side, the QR code. Typically up to 3, 4, or even up to 5k of data is possible to put into a QR code. So you just take a screenshot, if you want, of the QR code, and you have the data in the QR code, okay?

[00:03:23]
That's an option that I've seen a lot. Again, these are options to let the user own the data and get the data out, okay? Blockchain-based data storage as well, okay, through new JavaScript APIs that are available are also possible, okay? This is just to get off the standard sync to the server that needs authentication on and needs something to identify the user and a lot of stuff around that.

[00:03:55]
Being a good citizen, don't store what you won't use, remember it's user's device. Remember that even if you have a large quota, that quota is also living with other quotas, with other. And at one point, the space will be off, and if you don't have persistent storage, okay, your storage will be removed.

[00:04:17]
So if you are good citizens, you have a greater opportunity to still be there. So let's say browsers, yypically when they delete data, when there is storage pressure, typically they delete the older data. But also they try to find, okay, maybe within the older, we have one that is taking 500 megabytes.

[00:04:43]
Okay, let's go with that one first, okay? Clear the storage when it's not needed, don't leave that forever. Think about what will happen in the future. We change our websites, we change the data that we store. Well, think about versioning the data and the schemas, and every time there is a new schema when the user loads the new version of the app, delete all the data that your previous version left on users' devices, okay?

[00:05:16]
Best-effort first, remember that the data might not be there. So plan for the data not been there first. And then if it's there, well, we will improve the experience, like a progressive enhancement over data. Capture quota errors. This is important, cuz I've seen a lot of local storage usage, IndexedDB, that are not checking quota limits.

[00:05:42]
And they say, well, but quota is okay, because I have 2GB, I don't care. Yeah, but maybe your user is on an Android chip phone that is full. Maybe it's not a desktop, and maybe it's full, so that Android device has only one megabyte left, so when you try to save your IndexedDB, it doesn't work.

[00:06:06]
And then maybe you may end up with a broken database, you have some objects but not others, things like that. So plan for the possible errors, okay? Because in chrome, it's a percentage of your available space, and maybe your available space is nothing, okay? And offer the user way to get out, to get that user-generated data out of the web app, if possible, in different formats, in different ways.