Skip to content

Compile :common project for the web#354

Merged
simolus3 merged 6 commits into
mainfrom
common-web
Jul 7, 2026
Merged

Compile :common project for the web#354
simolus3 merged 6 commits into
mainfrom
common-web

Conversation

@simolus3

@simolus3 simolus3 commented May 29, 2026

Copy link
Copy Markdown
Contributor

This adds support for compiling (most) of the :common project for the web. This doesn't actually add web support, but it gets :common into a state where providing a web implementation of our SQLiteConnectionPool interface would make it run on the web. A future PR would provide that as a builtin option.

The key challenge here is that we assume synchronous SQLite calls in many places of the SDK. On the web however, preparing or stepping through statements is fundamentally asynchronous (as it requires worker communication). To reconcile this without a breaking change, we adopt this pattern:

  1. On non-web platforms, both blocking and non-blocking APIs are available (previously, we only had blocking APIs). Non-blocking APIs are implemented by just calling the blocking APIs in a suspend function, which is fine because we run the entire callback in a Dispatchers.IO context.
  2. On the web, only the non-blocking APIs are available.

In Kotlin, we can express this with expect interfaces:

  • In common code, we declare expect interfaces with only the non-blocking APIs.
  • In non-web targets, we use an actual interface also adding the blocking APIs. This allows us to preserve both source and binary compatibility, since blocking methods still exist in the exact same location.

To be able to use suspending functions, this adds asynchronous methods to ConnectionContext and Queries. This also refactors the implementation of Queries to use default methods based on useConnection.

On the web, we initially won't support:

  • RSocket (since browsers are supposed to offer backpressure for fetch() streams).
  • The attachments system (it uses some callbacks that currently only work with blocking APIs, so porting it to the web might require breaking changes).
  • The PowerSyncDatabase() factory method (only PowerSyncDatabase.opened is supported as opening databases is asynchronous on the web and would require a different API).

There's obviously a lot more to do, but this is an initial step to unblock web support.

@BierDav

BierDav commented Jul 5, 2026

Copy link
Copy Markdown

room3 1.0.0 is out 🥳 https://developer.android.com/jetpack/androidx/releases/room3

@simolus3 simolus3 marked this pull request as ready for review July 6, 2026 07:43
@simolus3 simolus3 requested a review from Manrich121 July 6, 2026 07:45
@simolus3

simolus3 commented Jul 6, 2026

Copy link
Copy Markdown
Contributor Author

Thanks for the heads-up @BierDav :) To manage expectations, it's worth noting that getting PowerSync Kotlin to work on the web will take a bit more effort than just depending on androidx sqlite for the web since we also need a custom sqlite3.wasm build containing the core extension. I want to explore a setup based on communicating with the worker we already have for the Dart SDK, which should give us everything we need (including a shared sync worker to coordinate across tabs). But that might take a a bit more time.

Manrich121
Manrich121 previously approved these changes Jul 6, 2026

@Manrich121 Manrich121 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy with the changes

@simolus3 simolus3 merged commit a31cf94 into main Jul 7, 2026
19 checks passed
@simolus3 simolus3 deleted the common-web branch July 7, 2026 08:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants