Feature: Temp solution for Bun websocket? about surrealdb.js HOT 8 CLOSED

This is now working for us in bun 1.0.15 as they have updated their websocket client

from surrealdb.js.

I kinda like this solution for running it in bun and I don't think its too much of a jump as there is already a src/library/WebSocket/[node.ts, deno.ts]

From your testing was tcp-websocket a drop in replacement for the standard websocket?

Currently I've been able to just use ExperimentalSurrealHttp as live support isn't required where I'm using it but would prefer using websocket if possible, but from what I've seen of the websocket client bug in bun it might be a while

from surrealdb.js.

Yes i agree, in terms of changes, i only had to modify the node.ts file (in the websocket folder) and just adding --platform node in the build script (just took the lazy approach here)

import TCPWebSocket from "npm:tcp-websocket";

function ModifyCloseMethod<T extends { new (...args: any[]): any }>(BaseClass: T) {
	return class extends BaseClass {
			// Override close method with a different parameter type
			close(code: number, reason: string) {
					super.close(reason, code)
			}
	};
}

const WebSocketClose = ModifyCloseMethod(TCPWebSocket);

class WebSocket extends WebSocketClose {
	addEventListener = this.addListener;
}

export default WebSocket;

(i haven't had time to fully optimise the code) but after doing that, i was able to get everything to work normally
thereafter.
However one other thing to take note is that, trying to send large data causes the
ws.addEventListener("message", (e) => {
to fail when trying to parse the message data as JSON

from surrealdb.js.

While we can differentiate between browser/node/deno, I'm not so sure if we can do the same for bun. Besides that, this will add unneeded overhead node_modules folder for node projects if pulled off.

My suggestion is to either wait until bun fixes their websocket implementation, or to patch the library. Will leave this issue open in case I find time to look into this

from surrealdb.js.

From what I can see in https://github.com/sxzz/unws/blob/main/package.json they use the global WebSocket "bun": "./src/native.mjs", so it might be able to be temp patched by making the tcp-websocket be global.WebSocket as the first thing done before loading surrealdb.
But also if this is a valid fix for buns web sockets then it should be apart of unws if `tcp-websocket is more complete than buns?

(I've not validated any of this, just based on a morning browse :D )

Also yeh valid points @kearfy especially the overhead since there's not really a way to do bun only dependences right?

from surrealdb.js.

You can probably detect some global constant that is only present for bun during runtime, but that's already extra overhead for dependencies.
Let's hope they fix it soon. You could alternatively overwrite the global WebSocket class maybe? Just thinking along with you all 😅

from surrealdb.js.

Hi! Author of tcp-websocket right here,

@LucyEgan

tcp-websocket is more complete than buns

It's a bit false because my implementation was first made to fix my particular own issue with Bun's WebSockets.

So my library has some not implemented features that I might look into because Bun developers may not fix that HTTP headers casing issue (after some discussion in their Discord)

I don't really know surrealdb.js so if there's crucial WebSocket features you need, just tell me and I'll make them my priority for my next updates.

About the additional dependency, I understand that might be not good.

Patching the global WebSocket may be a solution, but maybe you can install tcp-websocket as optional dependency in the library and then tell somewhere in the documentation that if people are using Bun, they have to install that optional dependency. Then in the library, just check if it's being run under Bun, if so take the tcp-websocket package if installed, otherwise the global WebSocket.

from surrealdb.js.

Closing as stale

from surrealdb.js.