gorilla-controllers VS websocket

I have been working on a few personal projects & was using Gorilla & I started out creating a few libraries to extend Gorilla (https://github.com/joegasewicz/gorilla-controllers) which separates the view logic from the controller. I created another one to add middleware & query params but that's when I thought I might as well just consolidate them in their own library.

Anyone using Gorilla might find this little library useful to simplify your template logic with controllers:

https://github.com/joegasewicz/gorilla-controllers

#go #golang #gorilla

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"