4 ms·

Not sure if this is what you’re looking for but I’m using it to embed SQLite in an app that’s both desktop (electron) and web-kinda-sorta. I say kinda-sorta bec

by mstade 7y ago

Not sure if this is what you’re looking for but I’m using it to embed SQLite in an app that’s both desktop (electron) and web-kinda-sorta. I say kinda-sorta because really what we’re doing is embed SQLite (and other dependencies) in an html page so our users can just open it straight up in a browser without having to be online or connected to any other systems, and still able to work (albeit read only for now.) The download time doesn’t matter to our users (and more often than not the file is loaded from a local file: url anyway) and the startup time is not spectacular but sub-second at most currently, so we’re happy so far. Except for some noob mistakes when implementing the PoC it’s worked remarkably well, much better than I though it would.

exikyut 7y ago
I never thought of replacing WebSQL like that. Cooool. Pretty sure Electron provides IndexedDB though. (Ref: https://nolanlawson.com/2015/09/29/indexeddb-websql-localstorage-what-blocks-the-dom/ https://nolanlawson.com/2015/09/29/indexeddb-websql-localsto..., vaguely https://nolanlawson.github.io/offlinefirst-2016-03/ https://nolanlawson.github.io/offlinefirst-2016-03/)
- mstade 7y ago
  The decision to embed SQLite had more to do with query capabilities than storage. We need to expose a query interface that is both flexible and powerful, and ideally it’s not something esoteric. We need something BAs can pick up without much or any additional training. With SQLite we both get the query engine and storage, but really it’s the former that’s important. While it may have started as a “what if” kind of PoC I think it’s gonna stick, unless we can find something that essentially gives us SQL the query language (superset is fine, subset not so much) and whatever storage backend is available, be it IndexedDB or something else. We tried various options, like AlaSQL and others, but embedding SQLite was pretty painless and gives a lot of bang for the buck. The only downside so far is that the embedded size is quite large, so we do take a small hit in startup latency (sub second still) and if we ever end up having a requirement to work across the internet (I doubt it) it’s going to hurt because we’d be looking at a 3mb+ download (quite cacheable though.) Anyway, point is our need was mainly SQL the language and not so much the storage, that’s kind of secondary, though SQLite really makes that part easy too.
  - exikyut 7y ago
    The thing is, I can't/don't disagree with you, in terms of arguing for SQLite over alternatives. Hearing the practical specifics of your edge case is (depressingly) insightful. I just realized the links I posted didn't include the article I had in mind when I went link-digging (and didn't properly check the results, woops). I found it: https://nolanlawson.com/2014/04/26/web-sql-database-in-memoriam/ https://nolanlawson.com/2014/04/26/web-sql-database-in-memor... Potentially interestingly, I re-found the link above via hn.algola.com, which also found me the comments (for the only time the above link was posted), at https://news.ycombinator.com/item?id=7661236 https://news.ycombinator.com/item?id=7661236. The top comment thread there points to https://github.com/kripken/sql.js https://github.com/kripken/sql.js, which was started pre-WebAssembly but now builds for WASM, and the network tab in devtools is telling me it's a 497KB download. It says it takes the position of providing a first-class JavaScript API instead of C bindings, and that you have to implement your own save/load<->import/export layer. You may have already discovered and discarded this possibility. FWIW, if using SQLite does stick, I reckon that an article (even a small one) about the journey/decision process/implementation gotchas/etc - and particularly details about the use cases, and why SQLite shines for your scenario - would probably be received very positively. Thanks for replying! (My fast response time was due to fun timing: I literally just opened my laptop this morning, checked HN, and saw your comment posted "0 minutes ago" :D)

by mstade 7y ago

exikyut 7y ago

I never thought of replacing WebSQL like that. Cooool. Pretty sure Electron provides IndexedDB though. (Ref: https://nolanlawson.com/2015/09/29/indexeddb-websql-localstorage-what-blocks-the-dom/ https://nolanlawson.com/2015/09/29/indexeddb-websql-localsto..., vaguely https://nolanlawson.github.io/offlinefirst-2016-03/ https://nolanlawson.github.io/offlinefirst-2016-03/)

mstade 7y ago
The decision to embed SQLite had more to do with query capabilities than storage. We need to expose a query interface that is both flexible and powerful, and ideally it’s not something esoteric. We need something BAs can pick up without much or any additional training. With SQLite we both get the query engine and storage, but really it’s the former that’s important. While it may have started as a “what if” kind of PoC I think it’s gonna stick, unless we can find something that essentially gives us SQL the query language (superset is fine, subset not so much) and whatever storage backend is available, be it IndexedDB or something else. We tried various options, like AlaSQL and others, but embedding SQLite was pretty painless and gives a lot of bang for the buck. The only downside so far is that the embedded size is quite large, so we do take a small hit in startup latency (sub second still) and if we ever end up having a requirement to work across the internet (I doubt it) it’s going to hurt because we’d be looking at a 3mb+ download (quite cacheable though.) Anyway, point is our need was mainly SQL the language and not so much the storage, that’s kind of secondary, though SQLite really makes that part easy too.
- exikyut 7y ago
  The thing is, I can't/don't disagree with you, in terms of arguing for SQLite over alternatives. Hearing the practical specifics of your edge case is (depressingly) insightful. I just realized the links I posted didn't include the article I had in mind when I went link-digging (and didn't properly check the results, woops). I found it: https://nolanlawson.com/2014/04/26/web-sql-database-in-memoriam/ https://nolanlawson.com/2014/04/26/web-sql-database-in-memor... Potentially interestingly, I re-found the link above via hn.algola.com, which also found me the comments (for the only time the above link was posted), at https://news.ycombinator.com/item?id=7661236 https://news.ycombinator.com/item?id=7661236. The top comment thread there points to https://github.com/kripken/sql.js https://github.com/kripken/sql.js, which was started pre-WebAssembly but now builds for WASM, and the network tab in devtools is telling me it's a 497KB download. It says it takes the position of providing a first-class JavaScript API instead of C bindings, and that you have to implement your own save/load<->import/export layer. You may have already discovered and discarded this possibility. FWIW, if using SQLite does stick, I reckon that an article (even a small one) about the journey/decision process/implementation gotchas/etc - and particularly details about the use cases, and why SQLite shines for your scenario - would probably be received very positively. Thanks for replying! (My fast response time was due to fun timing: I literally just opened my laptop this morning, checked HN, and saw your comment posted "0 minutes ago" :D)