ws VS wasmws

Then take a look at this article - https://www.freecodecamp.org/news/million-websockets-and-go-cc58418460bb/ - using external from Go std lib epoll implementation and https://github.com/gobwas/ws lib it's possible to reduce memory usage per connection drastically. Though keep in mind that this approach is not obvious to implement right and you better to go with STD lib.

Yes, but there are two excelent libs for golang websockets - https://github.com/gobwas/ws - https://github.com/centrifugal/centrifuge

Yes, I find https://github.com/gobwas/ws to be far superior. It has a lot more ability to customize and get high performance as well as a utility package that is much higher level and makes it easy to use. It doesn't have some of the problems of gorilla because they didn't have to support people already depending on it

There's https://github.com/gobwas/ws and https://github.com/nhooyr/websocket but neither have seen a commit in over a year

Oh, thanks! And sorry for still not switching to https://github.com/gobwas/ws :)

Hello, +1 to WebSockets. If you need to choose WS library – go with https://github.com/gorilla/websocket or https://github.com/gobwas/ws. You can also look at Centrifugo server (https://centrifugal.dev/, supports WebSocket, SockJS bidi transports, also EventSource, HTTP-streaming, GRPC unidirectional transports and many builtin features) or https://github.com/centrifugal/centrifuge Go library.

I prefer gobwas/ws because it has the high level "easy mode" (though some things will still be a small learning curve if you are used to REST mostly) and a low level API that you can dive into if you need very high performance and don't mind getting deeply into the details. It has the advantage of being written much after the most popular Gorilla websocket implementation which has some complexity and other issues that it can't totally remove in order to keep compatibility for all of its many users. It's also battle-tested via mail.ru. See A Million Websocket and Go for more details on its inception.

Thanks for writing this! I found it really great to use when I wrote https://github.com/tarndt/wasmws

Before looking at the readme, I thought this was an alternative to using https://github.com/tarndt/wasmws which lets you use gRPC over websockets so that you can use gPRC via WASM without needing an http to gRPC gateway. Now I'm understanding a bit differently. It looks like this uses protobufs but doesn't have anything to do with gRPC at all, instead implementing some of the communication parts of gRPC while ignoring the generation of services but instead focusing a bit more on message routing and pub/sub that you would probably still need NATS.io for if you were using gRPC.

The hijacking a websocket works very well, live in the future today! https://github.com/tarndt/wasmws

Everything said above is valid, but if you do think you have a need to transpile... consider running any Go frontend code as WASM rather than Javascript. A few years ago I started doing my frontends and backends all in Go and its been wonderful. I even wrote a library so I could use gRPC from my WASM/Go frontends rather than REST: https://github.com/tarndt/wasmws . Extra wonderful, at least for my tastes. Once caveat is if your brotli compressed, CDN/browser cached, etagged Go WASM is still to big, you can usually make it even smaller by using tinygo rather than the std tool chain for the compiling to WASM.

A while back I was writing a pure Go frontend app (WASM) and I wrote this so I could use gRPC rather than REST to talk to my backend: https://github.com/tarndt/wasmws