I am in the process of experimenting with an app using Ionic 5, Angular, Capacitor 3 and now I’d like to implement SQLite from @capacitor-community/sqlite.
I’ve found a tutorial online but it’s for a previous version of SQLite which has since seen a major refactor and is no longer correct.
Does anyone have any good resources where I can learn more about how to implement it other than the documentation on GitHub?
First thing I would recommend is finding three friends. Order them in terms of transigence: let’s say Alice is the most easygoing, Barbara is a little harder to convince, and Carol is downright stubborn as a mule.
Now have a conversation with each of them in turn, trying to convince them that your life would be better off with SQLite in this app. Only if you can get Carol to agree should you proceed.
SQLite is a PITA to work with. Ionic has done a great job of making it appear seamless whether it’s involved or not, but that arguably ironically makes the problem worse.
There are two main reasons I’d like to try to talk you out of using SQLite:
It only works on device, so you will either have to do all further development and testing in a device or simulator - no more lightweight desktop browser live reload environment - or put in a bunch of extra work mocking things out, and then worry that you still haven’t tested the SQLite stuff until you get on device.
It’s complete overkill for 90% of apps. If your app (a) needs to be doing complex joins of data that has to be organized in relational tables that (b) has to be completely functional in an offline environment, then SQLite is likely going to be worthwhile. If you (and your friend Carol) aren’t rock-solidly convinced of both of those conditions, steer clear.
I would first try implementing whatever it is that you’re trying to do using Ionic Storage. It will work using IndexedDB in any environment - including PWA and development live reload. Only if the fundamental limitation of the NoSQL key-value storage paradigm becomes a deal-breaker would I get SQLite involved.
Got to be honest, having tried working with it, I have realised it appears to be a complete nightmare.
I just did some research in to it prior to starting and I was pretty convinced it would be a good solution for what I want. It’ll mean I can essentially recreate the data from the API on the device and then run relational queries on it… but frankly I think I’d be better off just building a different API and saving myself the hassle of SQLite.
For what it’s worth, I think you have the right instincts here.
If you need more reasons to feel good about your decision, servers are great. You can make more of them whenever needed. You can improve performance either by throwing resources at the problem or by rearchitecting your middleware. Crucially, every improvement you make on the server-side gets instantly gifted to every user, allowing you to amortize the development and deployment costs accordingly. Same thing goes for improving and adding to the data that is stored there.
Contrast that to the “every install is an island” world of deploying everything. Every database revision requires a new app release version. Users with different versions see different data. If you’ve got trade secrets or proprietary stuff in your databases, your lawyers are going to hate hearing that, for technical reasons, you have to embed all of it in easily accessible fashion in freely-distributed app binaries.
The bigger your app binary is, the slower it is to download, install, and launch. Database files are dead weight here.
I agree, and thanks for taking the time.
I think I’ve decided on an @ionic-storage approach and probably do a little bit of caching to speed up some of the data which isn’t going to be changed on a regular basis.