I was watching this video from Steve Sanderson which demonstrates using SQLite with Blazor Web Assembly and I am contemplating using it in one of my projects. I am just trying to understand what the benefit is. It seems, from whatever information I was able to find, that the actual SQLite database resides in memory. In his project he is synchronizing it with IndexedDB for persistence. If that is the case, how is that better than storing your data as an object list in memory, and using Linq to query the objects directly, instead of Entity Framework to query from the SQLite database? You can also persist your objects to IndexedDB if that is required. I was never under the impression that it is a good idea to keep that much data in memory. My initial thought when seeing that you can use SQLite in Blazor was that it allowed you to keep data client side without keeping it all in memory. If that is not the case, what is the benefit of using SQLlite in a Blazor app?
A good rule of programming is KISS - Keep it Simple. So if the requirement of your app is satisfied by Linq to Objects, then complicating it with SQLite would seem to be the wrong thing to do.
However, in the video Steve S. does come up with requirement parameters that lend themselves to using SQLite - the application needs to process:
The use of SQLite here is not for persisting beyond client app memory.
So the answer to your question on the advantage of a Blazor app using SQLite is simply:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With