Feature: Replace Gorilla WS with Nhooyr WS about surrealdb.go HOT 7 OPEN

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.

from surrealdb.go.

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

from surrealdb.go.

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...

from surrealdb.go.

HI @ElecTwix

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

from surrealdb.go.

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

from surrealdb.go.

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?

from surrealdb.go.

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 :)

from surrealdb.go.