Websocket for UI interactive refreshing

go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD

https://gitea.com

MIT License

45.29k stars 5.51k forks source link

Websocket for UI interactive refreshing #25661

Open silverwind opened 1 year ago

silverwind commented 1 year ago

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.

delvh commented 1 year ago

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

silverwind commented 1 year ago

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

techknowlogick commented 1 year ago

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

KN4CK3R commented 1 year ago

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

lunny commented 1 year ago

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

silverwind commented 1 year ago

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.

lunny commented 1 year ago

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.

anbraten commented 10 months ago

linking https://github.com/go-gitea/gitea/issues/2287