Use Turbo Streams to push updates to panels

OSC / osc-reporting

Reporting on OOD jobs ran at OSC

MIT License

2 stars 0 forks source link

Use Turbo Streams to push updates to panels #24

Closed lukew3 closed 2 years ago

lukew3 commented 2 years ago

In a previous pull request, javascript was added to refresh all panels on a page by re-requesting the entire page of this app every so often from the client side. Instead of this, we would prefer that at an interval, the server pushes updates to each client panel instance

[x] #27
[x] #28
[x] enable simple turbo-stream
[x] finish this ticket by pushing updates from the cluster job to the panels through turbo streams.

┆Issue is synchronized with this Asana task by Unito

johrstrom commented 2 years ago

TurboStreams is what we want. we want the server wake up, render the template server side and then pass that html partial to the client over a websocket stream.

https://github.com/hotwired/turbo-rails#come-alive-with-turbo-streams

We may have to add action-cable?

lukew3 commented 2 years ago

@johrstrom I'm slowly making progress on this, but am currently stuck on an issue with action-cable. What I have currently is on the turbo-streams-updating branch at 1953db6. This should update the clusters 30 seconds after the page is loaded, but it looks like the action cable can't connect and open a websocket connection. In the network tab of the firefox developer tools, I'm getting repeating 404 errors for wss://ondemand.osc.edu/cable. Also, maybe you could point me to a better way of running the send_update function periodically in the background.

johrstrom commented 2 years ago

I'm getting repeating 404 errors for wss://ondemand.osc.edu/cable

It needs to respond to RAILS_RELATIVE_URL which would be /pun/dev/dashboard. I don't know how to configure that at the moment, but i'll bet there's something in config/cable.yml (which may or may not exist now).

Also, maybe you could point me to a better way of running the send_update function periodically in the background.

Somehow we need the controller to do this

start an activejob
schedule the active job (maybe it requeues itself, maybe the controller reschedules it)
relay the job's updates through send_update

It's sort of asynchronous behavior we have to coerce Ruby into a setTimeout type situation. I'm not very familiar with it myself.

johrstrom commented 2 years ago

Sorry, RAILS_RELATIVE_URL is an environment variable. You shouldn't have to set it, only configure action cable to use it (however that may happen).

johrstrom commented 2 years ago

I think this is fixed in #29 - at least as much as we need to right now.