SQLite WASM Devtools

[qwtel]

While basing SQLite Viewer on web technology hasn't been the best choice for performance and resource utilisation (though it does pretty well compared to other web UIs in that department), it has enabled the app to go places: Spun-off from the initial VSCode extension, the web version at sqliteviewer.app is now one of the top-ranked web-based SQLite tools. However, the app has more places to go:

As SQLite becomes more usable as an application database for web apps, thanks to the efforts the official SQLite WASM build, sql.js and wa-sqlite, the need for a dev extension grows by the day. While Chrome Devtools offer UIs for LocalStorage and IndexedDB, no such option exists for SQLite WASM. Since SQLite is famously not a web technology, it likely never will, either. Devtool Extensions are here to fill the gap, which are just somewhat special web apps under the hood. It so happens that I have a web-based GUI that's purpose built for SQLite that is ready to be ported. However, there are some missing pieces:

What's needed to make this happen?

• Most of what's outlined in SQLite Viewer – Server #61, specifically updated message passing and UI support for editing data
• A switch to wa-sqlite, since this module is pushing the state of the art in terms of browser VFSs, and the extension needs to be able to view all of them (if possible)
• Ideally reusing the web components used to make the builtin dev panels, to match the style as closely as possible.

Since I see no credible path to monetization for a devtools extension (and because I'd like to see it available for free), I will be relying on donations for this port.

If you plan on using SQLite WASM as an application database in your web app and would benefit form a devtools extension, please reach out to me at [email protected].

As of 06/09/24, work on this has not started

[rhashimoto]

A SQLite viewer in dev tools would be pretty cool. I have a suggestion that I think would expand its usability and make it a lot simpler to build.

My suggestion is to specify a debugging entry point for the web application to execute SQL, e.g. assigning window['sqliteviewer'] to a function that takes SQL as an argument and returns a Promise for the results in some standard form. Your extension would then delegate SQL queries to this function, e.g. with chrome.scripting.executeScript().

This would sidestep the issue of which libraries (official SQLite WASM, SQL.js, wa-sqlite, etc.) and virtual file systems to support. You would simply use the same database connection as the application, whatever that is. This also gets around virtual file systems that only support a single exclusive connection. And it would take a lot of complexity out of the extension that now wouldn't need to manage its own SQLite instance.

On the negative side, this would make it harder to open dev tools on an application that doesn't cooperate by publishing that debugging hook...but not impossible. Patching in a hook manually using the dev tools can be done. The hassle of redoing this on every relaunch can be somewhat lessened with snippets.

I think it is quite possible that you would gain more usage from increasing the SQLite varieties allowed than you would lose by depending on the application to cooperate, and with significantly easier development.

[qwtel]

Hey, cool that you found this repo. I've enjoyed reading your updates on wa-sqlite and comments in the SQLite forum when I was researching custom VFSes in sqlite wasm. Very insightful.

Yeah, a dev extension would be pretty cool. I think lack of a devtool/GUI is one of a couple of issues that's holding back broader adoption of sqlite wasm in the browser. Being able to inspect localStorage & IndexedDB is a big benefit. Obviously you've done a ton of work addressing the major issues.

This also gets around virtual file systems that only support a single exclusive connection

Yeah, I didn't know this at the time of writing, but I've since bumped into this issue a couple of times.

Fully agree with your suggestion.

On the negative side, this would make it harder to open dev tools on an application that doesn't cooperate by publishing that debugging hook

Publishing some snippets that developers can include in their build system for injecting the code along with the dev extension would go a long way. Or it might be possible for the dev extension to inject these snippets for the most common sqlite libraries itself? I haven't thought about it in detail, but I'm sure there's ways to improve DX.

Anyways, I don't see myself working on this anytime soon unfortunately. There's no pathway to a paid dev extension imo, and the other versions aren't yielding enough where I feel like working on this for free atm. Might change in the future, but nothing concrete yet.