Websocket for UI interactive refreshing #11156

New Issue

2025-11-02T09:29:15-06:00

GiteaMirror commented

2025-11-02 09:29:15 -06:00

Originally created by @silverwind on GitHub (Jul 3, 2023).

Feature Description

Currently we have Server-Sent-Events aka. EventSource for a few things but it's too unreliable because browser enforce a 6 connection limit per browser window and I think our implementation also has a number of unresolved bugs.

We should therefore switch EventSource to Websockets. From what I gather, suitable modules are:

https://github.com/olahol/melody convenient high-level API, but builds on top of deprecated gorilla/websocket
https://github.com/gobwas/ws slightly less convenient medium-level API
https://github.com/gorilla/websocket deprecated very low-level API

For the frontend side, I recommend SharedWorker similar to this that can communicate "events" that are simple JSON messages to all open tabs. Could initially also be done on main thread because workers are a very hard to debug in browsers.

Originally created by @silverwind on GitHub (Jul 3, 2023). ### Feature Description Currently we have Server-Sent-Events aka. `EventSource` for a few things but it's too unreliable because browser enforce a 6 connection limit per browser window and I think our implementation also has a number of unresolved bugs. We should therefore switch EventSource to Websockets. From what I gather, suitable modules are: - https://github.com/olahol/melody convenient high-level API, but builds on top of deprecated gorilla/websocket - https://github.com/gobwas/ws slightly less convenient medium-level API - https://github.com/gorilla/websocket deprecated very low-level API For the frontend side, I recommend SharedWorker similar to [this](https://github.com/go-gitea/gitea/pull/20543#issuecomment-1204032900) that can communicate "events" that are simple JSON messages to all open tabs. Could initially also be done on main thread because workers are a very hard to debug in browsers.

GiteaMirror added the type/proposal type/feature topic/ui labels 2025-11-02 09:29:15 -06:00

GiteaMirror commented

2025-11-02 09:29:16 -06:00

@delvh commented on GitHub (Jul 3, 2023):

I think this issue exists already, the original even has a bounty if I remember correctly.

@delvh commented on GitHub (Jul 3, 2023): I think this issue exists already, the original even has a bounty if I remember correctly.

GiteaMirror commented

2025-11-02 09:29:17 -06:00

@silverwind commented on GitHub (Jul 4, 2023):

I couldn't find it earlier. If it exists, I'll add my comment there instead.

@silverwind commented on GitHub (Jul 4, 2023): I couldn't find it earlier. If it exists, I'll add my comment there instead.

GiteaMirror commented

2025-11-02 09:29:17 -06:00

@techknowlogick commented on GitHub (Jul 4, 2023):

Ping @kdumontnu as I believe he was the one who put the bounty on it

@techknowlogick commented on GitHub (Jul 4, 2023): Ping @kdumontnu as I believe he was the one who put the bounty on it

GiteaMirror commented

2025-11-02 09:29:17 -06:00

@KN4CK3R commented on GitHub (Jul 4, 2023):

This is the one with the bounty but we talk about a general refreshing.

@KN4CK3R commented on GitHub (Jul 4, 2023): [This is the one](https://github.com/go-gitea/gitea/issues/18427) with the bounty but we talk about a general refreshing.

GiteaMirror commented

2025-11-02 09:29:17 -06:00

@lunny commented on GitHub (Jul 4, 2023):

We need a pub/sub abstract layer to replace modules/eventsource as backend of the websocket server side.

@lunny commented on GitHub (Jul 4, 2023): We need a pub/sub abstract layer to replace `modules/eventsource` as backend of the websocket server side.

GiteaMirror commented

2025-11-02 09:29:17 -06:00

@silverwind commented on GitHub (Jul 4, 2023):

For distributed gitea setups a pub/sub mechanism is indeed necessary so that events originating on gitea instance 1 can propagate to clients connected on instance 2. Often this is done through redis, which would then make it a hard dependency, at least for distributed setups.

@silverwind commented on GitHub (Jul 4, 2023): For distributed gitea setups a pub/sub mechanism is indeed necessary so that events originating on gitea instance 1 can propagate to clients connected on instance 2. Often this is done through redis, which would then make it a hard dependency, at least for distributed setups.

GiteaMirror commented

2025-11-02 09:29:17 -06:00

@lunny commented on GitHub (Jul 4, 2023):

For distributed gitea setups a pub/sub mechanism is indeed necessary so that events originating on gitea instance 1 can propagate to clients connected on instance 2. Often this is done through redis, which would then make it a hard dependency, at least for distributed setups.

For single and default configuration, we can have a memory pub/sub implementation based on golang channel and a disk implementation.

@lunny commented on GitHub (Jul 4, 2023): > For distributed gitea setups a pub/sub mechanism is indeed necessary so that events originating on gitea instance 1 can propagate to clients connected on instance 2. Often this is done through redis, which would then make it a hard dependency, at least for distributed setups. For single and default configuration, we can have a memory pub/sub implementation based on golang channel and a disk implementation.

GiteaMirror commented

2025-11-02 09:29:18 -06:00