I haven’t tried this framework, but just looking at some examples, the web socke...

uup · on Oct 3, 2022

Having recently implemented a WebSocket service in Go, the Javalin way seems preferable. This is what a similar Go version would look like:

    wsHandler := func(w http.ResponseWriter, r \*http.Request) {
        conn, err := upgrader.Upgrade(w, r)
        if err != nil {
            w.SendStatus(http.StatusInternalServerError)
            return
        }

        ctx, ctxCancel := context.WithCancel(context.Background())
        var wg sync.WaitGroup

        wg.Add(1)
        go func() {
            defer sync.Done()

            for {
                msg, err := conn.ReadMessage()
                if err != nil {
                    return
                }
            }
        }()

        msgPipe := make(chan []byte, 1024)
        wg.Add(1)
        go func() {
            defer wg.Done()
            for {
                select {
                case <-ctx.Done():
                    return
                case msg := <- msgPipe
                    if err := conn.WriteMessage(msg); err != nil { return }
                }
            }
        }()

        go func() {
            <- ctx.Done()
            wg.Wait()
            close(msgPipe)
        }()
    }

I like Go, but I found writing WebSocket code very annoying.

pron · on Oct 3, 2022

We don't have selectable channels yet, but they're not needed as much in Java as they are in Go, because often multiple channels are used to signal cancellation, whereas in Java there's a standard mechanism for cancellation (Thread.interrupt() at the low level, with Future.cancel being higher level, and JEP 428's structured concurrency being higher level still https://openjdk.org/jeps/428).