Coder websocket implementation in production grade app

Technical Discussion
1

Hey guys Quick question about coder/websocket + Echo v5:
Since Echo already runs each handler in its own goroutine, is it correct to just block the handler goroutine with the read loop directly — no extra go readPump() needed?

```
func (h *Handler) HandleWS(c echo.Context) error {
conn, _ := websocket.Accept(c.Response(), c.Request(), nil)
defer conn.CloseNow()

for {
    \_, data, err := conn.Read(c.Request().Context())
    if err != nil { return nil }
    h.hub.Publish(data)
}

}
```
And since coder/websocket handles concurrent writes internally, the hub can call conn.Write() directly without a separate writePump goroutine — is that the right pattern?

2

Yeah - you shouldn’t have to worry about spawning goroutines in your handler. Each handler will have its’ own goroutine. I think the Gorilla go readPump() pattern is based on the idea that they wanted the handler func to return and they wanted to manage the goroutines for websockets manually. Blocking the handler func is a fine pattern.