Revalidate on SSE canceled continuously in a high latency environment

[jason0598647]

Hi,

I have followed the SSE tutorial from here: https://www.youtube.com/watch?v=_7yJEC124jM

And adapted the source of the events to a Socket.IO API on the server side. When the server detects a change from the events API, it will send a timestamp SSE and the client will revalidate. The loader is just doing a GET of a list of instances from a local REST API on the server.

When working with low latency, ie. same geographic location, it works fine. I see the list component update various states as instances are updated. However, when I test from US West to AU East, I start running in to the following issue: (latency is probably around 450ms)

The list component is showing a bunch of tasks that run every minute (up to 50 on a page), and for the first 15 seconds or so of each minute they are continually updating their status as they start/stop. However in the higher latency test, the page never updates as page loads are being continually canceled until the page data is back in the original state.

Is there anyway to optimize the revalidate process to handle higher latency with frequent updates like this?

I'm thinking I may need to not use revalidate for this component and instead just push the field updates to the client for it to store in client cache instead.

(I'm on v2.5.1)

Here's a sample of the EventStream:

[sergiodxa]

You will have to increase the time you use to trigger the revalidation so instead of (e.g.) revalidating every 100ms do it every 500ms.

Another option as you mentioned is to instead of triggering a revalidation to pass the new data when it changes.

Ideally instead of using SSE to trigger a revalidation every 100ms or any other amount of time, you should trigger the revalidation when data changed, if you wanted to trigger in an interval you could do it client-side and you can control it better, the benefit of using SSE or WebSockets is to only do it when data actually changed.

[jason0598647]

The trigger is an Update event on socket.io from the API. It’s just that the events pile in for that 10-15 second period. But every block of events received from the socket io server in the API is triggering the SSE back to the client (if the data exists on the client page). The API dictates when events are sent (basic CUD events) as changes are made to the API data.

[sergiodxa]

If the actual data is changing this fast, you could throttle or debounce it client-side to give you time to complete revalidation.

[jason0598647]

I did try debouncing the event on the server side by between 250-1000, but it missed most of the events for some reason.
I might try a client cache instead and just do a revalidate for Create/Delete, and for Update I can send the record that was updated instead (which I have in the API event).
It’s probably better than doing a full get on the server side for every event anyway. If I have 15 or so tasks running every minute, they’ll all switch to “running” state at near the minute mark, and then switch back to “scheduled” as they complete over a 10-15 second period.

[jason0598647]

I ended up storing the server data in a useState on the component and just updating the instance data on an Update event (SSE is sending updated instances).
I left the Create/Delete event to do a revalidate.
Works nicely. Cheers