Question: Would it be possible to provide a bundle in a CDN?

[jyrimatti]

Hi,

I've used sql.js-httpvfs for some hobby projects and just tried sqlite-wasm-http, and it looks nice!

However, most my needs are small things that don't require any kind of build process. I usually try to avoid bundling if possible. I can of course keep bundling this library for myself, but being able to include it from a public CDN with a single script tag would have its benefits.

I'm no expert in JS stuff, but apparently Workers in scripts loaded from different origins have some limitations, would this be a problem? I wouldn't need any async support myself, but are Workers still a technical requirement from Sqlite side?

Any other issues that would prevent using from a CDN?

Thanks!

[mmomtchev]

You can produce a CDN version with rollup or webpack. Just make a small wrapper that does:

import { createSQLiteThread, createHttpBackend } from 'sqlite-wasm-http';
window.sqlite_http = { createSQLiteThread, createHttpBackend };

Bundle this and you will have your CDN version.

[jyrimatti]

Yes, that's what I'm currently doing, but there are two problems:

1. It's not available from a public CDN like jsdelivr.net, I have to host it myself somewhere. It would be awesome if this library could be used just by putting something like <script src="https://cdn.jsdelivr.net/npm/[email protected]"></script> to a HTML file, just like you use popper and bootstrap in the examples.

2. If I create the bundle and try to host it in a different domain than the one where my "app" is, I get:

Failed to create SQLite worker DOMException: Failed to construct 'Worker': Script at 'https://my.domain.com/bundle.js' cannot be accessed from origin 'http://localhost:8000'.

Does the library require using Workers? I tried using the "sync" backend but I got the Worker error anyway, am I perhaps doing something wrong?

[mmomtchev]

Even the sync version uses workers - you don't really have a choice with WASM - or otherwise you will block the main UI thread. The difference between the two versions is that the SharedArrayBuffer version can share the cache between different workers - which can greatly speed up retrieving the data. If you use only a single connection, there is no difference between the two versions.

Sorry, I forgot that cross-origin workers were blocked, I hoped that same-site did allow them, but the answer is still no.

You are pretty much out of options for this - you must host your web workers on the same hostname (and port number) as the main HTML file. There used to be a special loader for webpack 4 that loaded the file in a Blob but I do not recommend you to use it.

[jyrimatti]

I see.

The reason I asked was that I made an experimental extension for Htmx: https://github.com/bigskysoftware/htmx/pull/1969 It would have been nice to take it into use only by adding a script tag for the extension and another one for sqlite-wasm-http, but it seems that cannot be done.

If it's possible, it would be great if you could provide a bundle (with as few files as possible, I couldn't get below 5 js plus 1 wasm) to host so that it would be directly downloadable (from jsdelivr or github or wherever) to spare users from going through a bundling process? Yes, the users would need to download the files and host them next to their html, but at least wouldn't need bundling.

What do you think?

[mmomtchev]

Alas, this is a security restriction in the browser. There are workarounds for some browsers but, AFAIK, there is no universal solution. All JavaScript code that is going to be run in a thread must come from the same origin URL as the main HTML.

[jyrimatti]

Just to let you know: The best I could come up with was to offer the files next to the Htmx extension here: https://www.npmjs.com/package/htmx-sqlite The user still has to copy the files to where they host their html, but this is what it is. Fortunately only an issue for demos, ad-hoc experimentation and jsfiddle kind of stuff.

I’m gonna close this.