Hey @ElecTwix

I also like https://github.com/nhooyr/websocket for many different reasons. The most useful for me was that it can work when you compile your golang to wasm.

I see you have already jumped the gun and are doing it here: https://github.com/ElecTwix/surrealdb-custom.go. Are you planning to try to merge upstream If the SurrealDB maintainer wants to take it ?

https://github.com/btwiuse/wsconn/blob/main/go.mod looks to be an adapter that supports both gorilla and nhooyr. its mint be another option...

Hey @gedw99

I also like https://github.com/nhooyr/websocket for many different reasons. The most useful for me was that it can work when you compile your golang to wasm.

I didn't take that to count thanks for pointing that out.

I see you have already jumped the gun and are doing it here: https://github.com/ElecTwix/surrealdb-custom.go. Are you planning to try to merge upstream If the SurrealDB maintainer wants to take it?

I'm a big fan of SurrealDB and would love to contribute. While PR #127 wasn't accepted, I'm open to creating PR that introduces Nhooyr WS to go driver with the SurrealDB team's vision if they're interested in the future.

https://github.com/btwiuse/wsconn/blob/main/go.mod looks to be an adapter that supports both gorilla and nhooyr. its mint be another option...

Looks good, but I need to confirm compatibility with the gorilla's custom system type. I'll look into it.

HI @ElecTwix

what's required to get the Nhooyr WS accepted though ? Maybe I dont understand what you're suggesting ?

HI @ElecTwix

what's required to get the Nhooyr WS accepted though ? Maybe I dont understand what you're suggesting ?

Hi @gedw99,
Nhooyr WS ready to merge; awaiting approval from SurrealDB team. for context is rejected once with: PR

Heya, thanks for creating this feature request @ElecTwix and ongoing enthusiasm and efforts to improve the driver for everyone!

Overall, not opposed to changing the library. Personally I am not too familiar with the golang websocket space, but having had a search it seems that this library has a lot of performance benefits
https://github.com/gobwas/ws

One thing that stands out is that Nhooyr supposedly handles Context, whereas I haven't immediately been able to see that in gobwas. If gobwas supports context then I think that may be preferable. And they should both work for WebAssembly, seeing as gobwas does not have dependencies that would prevent that https://github.com/gobwas/ws/blob/master/go.mod

What do you think?

Heya, thanks for creating this feature request @ElecTwix and ongoing enthusiasm and efforts to improve the driver for everyone!

Thanks for your kind words @phughk.
I'm happy to help SurrealDB and everyone that uses it.

Overall, not opposed to changing the library. Personally I am not too familiar with the golang websocket space, but having had a search it seems that this library has a lot of performance benefits https://github.com/gobwas/ws

I know gobwas, it is great. For the test, I will also create an implementation for surrealdb to see the difference between both.

One thing that stands out is that Nhooyr supposedly handles Context, whereas I haven't immediately been able to see that in gobwas. If gobwas supports context then I think that may be preferable. And they should both work for WebAssembly, seeing as gobwas does not have dependencies that would prevent that https://github.com/gobwas/ws/blob/master/go.mod

What do you think?

gobwas doesn't have context support out of the box but it can be implemented, the problem with gobwas seems like it will need more work to maintain but I'm not sure like I said second answer I will create and we can decide afterward

I've been evaluating the gobwas WebSocket implementation. While it performs well, I have some concerns about its suitability for our project. Here's a breakdown of my findings:

• Non-Idiomatic Go: Using gobwas might require writing code that deviates from idiomatic Go practices. This can lead to maintenance difficulties down the line.

• Similar Performance with Idiomatic Go: The nhooyr implementation appears to offer comparable performance while adhering to idiomatic Go conventions, potentially making it a more sustainable choice.

• Limited Client-Side Examples: gobwas seems to lack a comprehensive set of official examples for client-side WebSocket usage. This could make it challenging to integrate it effectively into our project.

I think we should go with nhooyr's version I will create PR replace gorilla ws still we can discuss I just want to gain sometime while waiting.

@phughk I know you are not related to go but we started conversation if you have time could you check thanks :)

Just adding this update here. Coder took over maintenance of the nhooyr/ws package a month ago. It appears that nhooyr developed it while working at Coder. They seem to be mature, well-funded etc.., which can only bode well for the package.

The new repo is at https://github.com/coder/websocket

Here's another option that seems promising

https://github.com/lxzan/gws?tab=readme-ov-file