search

evoluhq / evolu

A local-first platform designed for privacy, ease of use, and no vendor lock-in
https://evolu.dev
MIT License
1.39k stars 51 forks source link

COEP and COOP required headers conflict with 3rd party scripts, such as payment gateways #309

Closed jericopulvera closed 7 months ago

jericopulvera commented 9 months ago

As mentioned by @steida, "those headers are required by the official SQLite WASM library. The only possible solution is to use an alternative unofficial SQLite WASM, this one: https://github.com/rhashimoto/wa-sqlite. It's not something Evolu supports out of the box, but we can add it if someone really needs it."

It would be great if we could have an option to use wa-sqlite instead of the official SQLite WASM library.

steida commented 9 months ago

If you need this feature ASAP, feel free to send PR. It should be relatively easy. The hardest issue to figure out is how @evolu/common-web and @evolu/react should be configured.

rhashimoto commented 9 months ago

The official SQLite WASM added support for another OPFS virtual file system, opfs-sahpool. This VFS has its own limitations - in particular it doesn't support multiple connections to the database - but it doesn't require COOP/COEP and once the database is open it provides the identical API. It's apparently also significantly faster.

If you can live with a single database connection then that might be an easier modification than changing SQLite WASM implementations. In some cases it's possible for multiple contexts to share a connection but I don't know if that would work here.

steida commented 9 months ago

@rhashimoto Hi! Thank you for the comment. I admire your work.

I thought about opfs-sahpool, but Evolu really needs to support multiple tabs, so we have to build a robust API around Web Locks and other APIs first. As you demonstrated, it's doable. I plan to do it once I solve other currently more important Evolu issues.

steida commented 7 months ago

@rhashimoto I think the most straightforward way is to use SharedWorker, and for Chrome Android dedicated Worker, I believe they will support SharedWorker soon. What do you think?

related https://github.com/rhashimoto/wa-sqlite/discussions/81

rhashimoto commented 7 months ago

@steida Using a SharedWorker is fairly straightforward. I don't think I would call sharing a dedicated Worker straightforward, but it can be made to work.

I don't think SharedWorker is coming to Android anytime soon. The chromium bug has been around for 10+ years with no developer comment since 2021. It also doesn't show up as a goal for Interop 2024 - maybe we should try to get that on the list for Interop 2025 when the call goes out later this year.

steida commented 7 months ago

So, I solved it with Web Locks and BroadcastChannel only. It's probably not as efficient as dedicated broadcast channels, but it's simple and works everywhere.

steida commented 7 months ago

Done