Persisting Data

[00:00:00]
>> All right, so I just have one more app that I kinda just wanna take a tour of and kinda show a little bit. Which is, there are a lot of applications that need to persist data over a longer period of time, right? And there's just some practices around that as well.

[00:00:25]
And so this application, I just added it to do, I want to quit the app, I want to come back. And I want my data to be there, right? And again, the way that most native apps, a lot of native apps do this, is they'll store it in a database, SQLite being a very popular one, because the SQLite database does not involve installing postgress and spinning up a server.

[00:00:52]
It's usually a file that is database, right, that can theoretically hold on and persist things that you can query. And there are a whole bunch of ways you can do this. You can use just use the SQLite 3 library, directly, you can use Connects, which is what I'm using, just an abstraction over that.

[00:01:12]
There's Prisma which is super great. You can use all sorts of other, I mean, you can even use the web technology like IndexedDB or any of those things as well. It doesn't matter. The general principles here are what I care about more than anything else. A few notes is that if you're not using Eletcron Forge, you do need to use this library called Electron rebuild.

[00:01:35]
Because, obviously, compiled native modules like SQLite or what have you, are not only OS specific but also a version of node specific. Back in the day when we all used node sass, which was the C bindings on LibSass. You knew that every time you bumped a version of node, you had to basically blow out all your node modules and recompile everything, because all your compiled modules are built against the version of node.

[00:02:04]
And on top of that, they're all usually OS specific as well. So what Electron rebuild does is it, cuz the version of node where you run an npm install, it's probably not the version that Electron is running, right? So obviously, if you just do an npm install, you will have the wrong version already, unless you have to the build, just assume you will have the wrong version.

[00:02:27]
And then by the time you go to build this for any given, or package this for any given OS, by definition, whatever you npm installed on is almost definitely the wrong one. So if you're not using Eletcron Forge, then you do need to use this library called Electron rebuild, which will just, by definition, rebuild the native modules ,appropriately, for that version of Electron on the OS that you're running, right?

[00:02:52]
If you're using Eletcron Forge, then you are using Electron rebuild, you just don't know it, and it is handling that for you. And that's true for any of these kind of native modules in this case. The other thing to think about is, where do you put this database, right?

[00:03:10]
If it was just a Node project, you'd put it in the directory, right? But that's not where OSes store your personal data, right? In Windows, it's percent sign, all caps, app data, percent sign, something or else, and this place that is like a known place to store user application data.

[00:03:29]
On Mac OS, it's your library folder and some sub directories in there, so on and so forth, right? So you wanna put user data files in the place in the OS where native apps put user data files, right? And again, that is different for every OS but to no one's surprise, right, there is an abstraction in Electron for doing that, so this app.getpath, and there's a bunch of these.

[00:04:00]
If I kind of just look here, you can see there's a whole bunch of paths that you can get to, including desktop and document. So if we were doing, there was a default directory for the show open dialog, in the first app, you could, theoretically, target it at the desktop documents, downloads, soap music, right, cuz people actually put stuff in the music and pictures folders, I guess.

[00:04:24]
So on a temp directory, videos, the user data and app data are where you kind of store, app data, I think, is global and user data is the directory for that given user logged into the machine. But it is the place where you can store those things. So by definition you do wanna make sure that you are storing stuff in the correct spot.

[00:04:47]
And that you've got the setup to build the native modules for the different versions of node and Electron and platforms you're working at. Again, Eletcron Forge handles this all out of the box. Electron rebuild itself is just a post install, you just run it and it will do that for you as well.

[00:05:07]
But like I said, unless you have a reason not to use Eletcron Forge, it's almost always better to use Eletcron Forge. All of the best practices are built in, and a year or two ago, it wasn't an official, official electron project, it was a user land kinda project.

[00:05:21]
Now it is part of the Electron project, so it is an officially supported first party tool, and so legacy apps is a great reason not to use it. I'm running out of good reasons not to use it. And beyond that though, since your node process is no different, other than going through a not particularly Electron-specific run through about how SQLite 3 works and how Connects is an abstraction over it, and me creating a table.

[00:05:58]
After that, it's just creating a bunch of methods to pull stuff in plus a valid database and the IPC around that. Right, and again, you might choose to use Prisma, I would probably use Prisma. But I wanted to keep it at least somewhat agnostic, without too much to read if one was interested in reading this later.

[00:06:15]
But the important parts are like to put any files that you're storing that are unique configuration files in the right place. And to understand that building native modules comes with a certain amount of headache in and of itself. So is local storage the right answer? Maybe, right? Is just writing to a text file in that app user data path the right choice, if you need that, or JSON file that you just read from and write to?

[00:06:42]
Possibly, right? Those are all very valid options, and it's as much as you need and as little as you can get away with. If you need to write some SQL to query stuff, yeah. SQLite 3 or some other, there's a thousand little file system based databases now. The thing is you have all of node so they're all various things that you can use, right?

[00:07:02]
But then you also have all the web, the cache API service workers, and everything along those lines are also available to you at the same time. And either one of those can be the right choice, depending on what you're doing. But there are just some things to think about if you are storing files.

[00:07:18]
You might not have permission for a given user to write in the applications folder in and of itself. To be clear, I know how macOS works a little bit better than I know how Windows works, right? Technically in macOS, if we go into Finder, and one way if you wanna ever see if something's an electron app, in macOS every application is technically a folder, right?

[00:07:43]
And so could you write in there, if you go into like notion, show package contents, it's a folder? A great way to see if something is an Electron app is just go to the show package contents and go into the frameworks. If you see Electron in there, that's how you know it's an Electron app, right, so theoretically, could you write to a directory in here?

[00:08:03]
You totally could. Should you? You probably shouldn't. Look, I wonder what that app directory is, look a package JSON. If you didn't use the app folder you'd be writing in here, which now means it's shared across all the users, and also you might not have permission to. Look they're using Eletcron Forge, and all those kinds of things, and you can kind of do all those things, but just making sure you're trying to write to the correct directory.

[00:08:29]
I guarantee you they are not writing the app data into here, this is just the actual JavaScript code, so on and so forth. I was about to say, did they minify it? Theoretically, I guess you could probably go in here and modify the code for notion or whatever if you wanted to extend it.

[00:08:47]
Don't cuz every time it downloads, it'll all be blown away. But yeah, just trying to make sure that you are putting the correct directory. And again, If you're not using a tool like Eletcron Forge, if you're using Electron Forge, just don't think about building against the version of Electron.

[00:09:02]
If you're not using something like Electron rebuild, incredibly important, but also, my major goal in this kind of talk right now is to put it into your head that yeah, you can write to a database and persist data, right? It doesn't have to be just like stuff you're loading.

[00:09:16]
Or you could load stuff from an external server, right? Or you can do both, cuz ideally, your app, if it's gonna be a desktop app, should probably work offline, right? Maybe it is Navigator.online or is online, go fetch new data. A lot of the ideas of progressive web apps probably apply here as well, except above and beyond just service workers and stuff along those lines, you literally have a server, right, and the ability to persist stuff on that machine and do things, right?

[00:09:47]
As we saw before, your Electron app can theoretically be somewhat headless as well and exist in that sense also, right? And so there's a lot of really interesting ideas and things along those lines.