Cannot use drift web with nested paths

[elitree]

Hi all, I'm running into an issue with drift web. It might not be a proper bug, but I can't tell, so I'm posting here as a start.

I have been really pleased with the functionality of drift web and how few changes it took to reuse our mobile cache implementation. We are using it in a prototype version of our mobile flutter app, and it works great in development (dev builds on our local machines, which serve to http://localhost:some_port).

Our prototype version is being served from a URL with a subpath (I mean, something like https://blah.com/lf-web/ as opposed to https://blah.com). This works fine for most of the app assets when I run the command with the --base-href command (i.e., flutter build web --release --base-href="/lf-web/"... except for the drift assets. If I run that build command, and try to serve at that path (the app is being served at https://localhost/lf-web/), I wind up getting 404 errors for the drift assets:

The rest of the app assets are properly accessed from the /lf-web/ subfolder.

The same thing happens if I build the example drift app (upon which I based my app's drift setup) -- the drift assets aren't served properly. Looking at these lines: https://github.com/simolus3/drift/blob/develop/examples/app/lib/database/connection/web.dart#L12-L13

... I wondered whether removing the leading slashes would allow the correct relative path to be determined, instead of using the root. However, I still get an error for a missing map file when removing the leading slashes:

This seems to prevent the worker from loading (this also happens with the example app). So, that's not a fix by itself.

I should add, things work fine when I serve the app from https://localhost.

Again, I'm not clear on whether this is a bug in drift, or somewhere else. It's also possible I have a misconfiguration on my server's end. I'm kind of hoping that someone else out there ran into this and solved it already, or has some workaround. If anyone's been able to successfully serve a drift web flutter app using the current example app's web worker implementation, please let me know.

Thanks,
Eli

[elitree]

PS - in my research for this issue, I came across an interesting bug... long story short, don't test flutter web apps on a nested folder named "test": dart-lang/webdev#1965

[elitree]

One other note - we didn't encounter this issue in the previous incarnation of drift web's example app setup (using this version of web.dart, for instance: https://github.com/simolus3/drift/blob/b4b4e350dd3aadef5e0254cfa1cf168ce55a7fac/examples/app/lib/database/connection/web.dart).

[FaFre]

Hi all, I'm running into an issue with drift web. It might not be a proper bug, but I can't tell, so I'm posting here as a start.

I have been really pleased with the functionality of drift web and how few changes it took to reuse our mobile cache implementation. We are using it in a prototype version of our mobile flutter app, and it works great in development (dev builds on our local machines, which serve to http://localhost:some_port).

Our prototype version is being served from a URL with a subpath (I mean, something like https://blah.com/lf-web/ as opposed to https://blah.com). This works fine for most of the app assets when I run the command with the --base-href command (i.e., flutter build web --release --base-href="/lf-web/"... except for the drift assets. If I run that build command, and try to serve at that path (the app is being served at https://localhost/lf-web/), I wind up getting 404 errors for the drift assets:

Pleas note that the --base-href is only taking affect (per default) in the html/js world. It is injected into the index.html during build time:

<!--
    If you are serving your web app in a path other than the root, change the
    href value below to reflect the base path you are serving from.

    The path provided below has to start and end with a slash "/" in order for
    it to work correctly.

    For more details:
    * https://developer.mozilla.org/en-US/docs/Web/HTML/Element/base

    This is a placeholder for base href that will be replaced by the value of
    the `--base-href` argument provided to `flutter build`.
  -->
  <base href="$FLUTTER_BASE_HREF">

Since the drift worker is loaded by drift afterwards, and not linked directly, the base path is not taken into consideration. I don't know if it is actually possible to access the set base path by drift during runtime (maybe by using the html package). I think that will require some further investigations.

... I wondered whether removing the leading slashes would allow the correct relative path to be determined, instead of using the root. However, I still get an error for a missing map file when removing the leading slashes:

This seems to prevent the worker from loading (this also happens with the example app). So, that's not a fix by itself.

I should add, things work fine when I serve the app from https://localhost.

You can ignore this error. This file is getting requested by the debugger to provide symbols for debugging (and the debugger is getting started automatically as you open devtools).

You can also confirm the presence of the worker by checking the available implementations using WasmDatabase.probe() from yesterdays 2.11.0 release. When you see opfs (by having a compatible browser of course), the worker is loaded correctly.

[simolus3]

Thanks for the report! But things seem to be working for me as soon as I remove initial slash in the urls used to load the worker.

I don't know if it is actually possible to access the set base path by drift during runtime

When starting workers from the document context, drift will just pass the uris to the relevant web APIs unchanged, which will resolve them relative to the current base url. When a worker needs to spawn a copy of itself, it uses Uri.base, which should resolve to the absolute URL of that worker.

I ran flutter build web --base-href="/baseref/" and started serving the build/web/ folder under /baseref. Visiting the page works with entries showing up. For me, this setup uses sharedIndexedDb in Chrome and opfsShared in Firefox. Both of these require workers, so it seems like it's possible to get drift working with a base href.

Again, I'm not clear on whether this is a bug in drift, or somewhere else. It's also possible I have a misconfiguration on my server's end

Is the app non-functional for you after removing the initial slashes? Or is there just a single message about the source map not existing.
I'll remember to remove the source map directive from future workers published as an attachment to drift releases on GitHub. In the example from the repository, the drift worker is built via build_runner which is helpful to test unreleased changes easily. The build system inserts the source map directive there and I don't think I can easily change it, but as @FaFre said that error is probably not relevant.

[elitree]

Thank you so much for checking on this and confirming that things should work in this scenario! And that the source map error was irrelevant.

I think I had somehow copied an old version of sqlite3.wasm into the web/build folders for the example app, and that was causing the example app to break. I can run the example app just fine now with the correct version of the wasm file. Not sure how I did that, since it should be symlinked in there to begin with.

Now that I can run the example app again, I should be able to track down the differences between my app (which is still experiencing issues) and the example app.

Thanks again. Should I submit a PR to remove the leading slashes in the example app's web initialization?

[simolus3]

Initially, I was worried about what would happen if one uses a navigation solution that pushes different URLs into the navigation stack? E.g. if the app is then opened with https://app.example.org/users/123, would a relative path still work? Knowing about <base> I guess yes, so I think the example should be changed as well. A PR would be great, thanks!

[elitree]

I opened #2565 to remove the leading slashes. Thanks again.