feat: default to newClientImplementation

[stevensJourney]

Overview

We currently have two options for connecting to the PowerSync service:

• The Rust client (called the newClientImplementation in Swift)
• The original Kotlin syncing implementation

Previously, the Rust client has been an experimental opt-in feature.

The Rust client has been stable for a while now and is the primary target for new features. The underlaying Kotlin SDK now uses the Rust client as the default from v1.9.0.

This updates the default implementation to be the Rust client (newClientImplementation = true). The option to disable the Rust client, and fall back to the legacy client is now deprecated.

Improvements

The old client uses HTTP streams to connect to the PowerSync service. The underlaying networking library currently has an issue which can cause high memory usage when streaming large volumes of data.

The newClientImplementation uses a WebSocket communication layer which has an additional backpressure layer. This results in stable memory usage when streaming large amounts of data.

Potentially Breaking Changes

The WebSocket layer does not currently support reporting networking logs via SyncRequestLoggerConfiguration. Code relying on SyncRequestLoggerConfiguration will no longer report any logs.

[stevensJourney]

Unfortunately, SyncRequestLoggerConfiguration is not marked as experimental. This could be considered a breaking change.
We should do some more investigation to see if we could possibly support logs with WebSockets.

[simolus3]

That is a good point, but I think in practice logging with WebSockets is tough since everything is in binary anyway. We probably need something custom here (even if we get the ktor Logging plugin to log for WebSockets, we'd log RSocket frames which is probably not that useful).

We could also consider an option on the Rust sync client to emit logs for lines it has received, since it has a bson decoder and a serializable IR for sync lines.

[stevensJourney]

I believe the logging should currently only be used for the /sync/stream and write-checkpoint routes.

IIRC the standard logging does not expose the server sent events in realtime for the HTTP method. The main options were:

• info Which includes the URL and method of the request
• headers the info above plus the requests headers
• body which is the entire body (I recently discovered this) - not on a per message level, only logs once the request is completed, for the /sync/stream method this is essentially a memory hog waiting to happen.

Having similar functionality - or even more improved functionality when it comes to the body - would be nice for WebSockets. I agree, due to the differences in the implementation, I imagine we'd need to implement our own layer for this.

The main question is if we should delay the switching of the default implementation until we implement this (if we decide to implement it).

I get the feeling that a strong notice for the change in functionality should outweigh the potentially large memory usage of the old implementation.

[simolus3]

I get the feeling that a strong notice for the change in functionality should outweigh the potentially large memory usage of the old implementation.

I agree with this, we should clearly mention this in the changelog and release notes.