@f0ssel I don't have much information on polling, but I'm curious where you got this pattern from. I've seen server-side events before, but I haven't seen this! Seems reasonable though... so not sure why I haven't seen it.

BTW this is pretty much the exact same as server-side events.

Yeah I'm unfamiliar with Server Side Events, my brief look seems like it's a javascript websocket standard. If there's anything I need to change to make this PR compatible with that web API I'm down to do so, would just like to be pointed in the right direction.

As far as where this is coming from, it's just porting a trimmed down version of what we do in V1 for the watch-stats, devurls/watch-status, etc.

Ahh, I'm more so wondering how other products attack this polling problem. I know Discord has a WebSocket that updates information

I'm not sure but I'll break down my thoughts so far

I think there's a few things we could improve here like:

• Multiplex updates to many different entities over the same websocket instead of opening multiple
• Only send updates on changes or on a backoff if data has not changed
• Gracefully handle errors instead of closing the websocket connection

But I've chosen this way so far because:

• The workspace entity having near-real-time updates seems like it will get us pretty far, I don't think there's plans to have other resources that will use this pattern.
• We already have code to support this pattern on the frontend and I'm optimizing for not adding more scope for community MVP.
• It's a familiar pattern from V1 that seemed to work fine, I don't think we've had much issues around it at the api layer.

I like this approach because in the future we can optimize the backend by removing unchanged values and/or replacing the internal DB polling loop with some kind of pub/sub system, without having to change the API at all.