centrifuge VS websocket

BTW, Centrifugo is based on https://github.com/centrifugal/centrifuge Go library which may provide much more control and flexibility for Gophers than a standalone server and can be embedded to any Go app leveraging all Centrifugo client SDKs.

There are libraries which provide more advanced APIs for creating real-time applications, for example https://github.com/centrifugal/centrifuge

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

What https://github.com/centrifugal/centrifuge does:

Have you considered https://github.com/centrifugal/centrifuge? It also uses Gorilla WebSocket for WebSocket transport at the moment – but it's hidden inside and may be replaced if needed since Transport interface is pluggable. It's more heavyweight though than both Melody and Gorilla WebSocket but provides much more functionality out-of-the-box.

Not a Socket.IO compatible but maybe you will find it useful/interesting: https://github.com/centrifugal/centrifuge

Thanks! BTW, Centrifugo's core is based on https://github.com/centrifugal/centrifuge Go library - which theoretically can be more flexible and extensible solution for Go developers than Centrifugo server since server dictates some auth/permission/channel/api rules.

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.

What I can say is that if you will use Gorilla Websocket (https://github.com/gorilla/websocket) (it's archived now unfortunately, but still super robust) - then you can go to sth like 15-20kb per connection - see https://github.com/FZambia/go_websocket_memory - to achieve this you need to reduce read buffer size, reuse write buffers, use goroutine after hijacking connection (following chat example in Gorilla WebSocket repo).

No Bugs? https://github.com/gorilla/websocket/issues Even if that were true at the time of stoping development, "No bugs" is something that can never be said for any software. I really wish this community stopped recomending to use abandoned libraries if only for the potential Security issues. A not maintained Library is a very lucrative target for vulnerability hunting.

The Gorilla WebSocket License says:

We'll be using WebSocket library: "github.com/gorilla/websocket" ❣️

package github.com/gorilla/websocket is not a main package

As for Websockets, (https://github.com/gorilla/websocket) it uses ws.NextReader() to handle heavy loads of connections.

I'm looking to build a game server that uses web sockets to communicate with clients, I've looked into some of the libraries and the main ones seem to be gorilla websockets and melody.

If this is what your import looks like "github.com/gorilla/websocket" that's wrong it should be just "github.com/gorilla/websocket"