Question related to Inactive Users

[kefniark]

Hi there,

Taking a look at this library as a replacement of websocket to use with urql, looks really cool.
Just wondering, if there a way (in graphql-sse or urql) to close SSE connections automatically after a certain time when users are inactive.

Run into the issue in the past with lot of open ws connection to the server, mostly caused by forgotten tabs. Often having to rely on timeout at the load balancer level and limited retry.

Any idea or recommendation to solve this issue with this library ? Any equivalent to keepAlive in graphql-ws ?

my guess is that a frontend solution is probably more accurate at detecting inactivity, can pause the subscriptions, and let the lazy option automatically close the connection.
Where a network solution would be easier to implement but based on arbitrary timeout numbers and can cause some side issues, with active user who will never receive their events because they already reach the timeout.

[enisdenjo]

Hey hey, graphql-sse and graphql-ws are both in lazy mode by default - they'll establish a connection with the server exclusively if there's a subscription running. I'd say the best way to manage inactive users is to handle it yourself since there's not a single sweet spot that can satisfy everyone.

Additionally, both graphql-sse and graphql-ws are isomorphic, they can run in a browser and in a Node environment. Bundling browser primitives is therefore a no-go. The isomorphic solution here would be to use some magic numbers for inactivity detection, and I don't really like magic in code.

One way of approaching the problem, on the browser, is to simply hook onto some great browser events that help with user activity detection. There are many to choose from, ranging from mousemove events up to visibilitychange events that emit when the window/tab goes in the background or comes to the foreground. If you go down the visibility change road (which I guess is a good fit for your use-case), you may want to combine a simple timeout with the visibilitychange event, a debounce per se, so that the unsubscribe happens after the user puts the window/tab in the background and some time had passed - makes for a smoother experience altogether.

Any equivalent to keepAlive in graphql-ws ?

How would the keepAlive help here? graphql-ws's client option keepAlive is "the timeout between dispatched keep-alive (pings) messages". Same on the server-side.

[kefniark]

Thanks for the feedback 👍

Just as a follow up, I tried different things and finally my solution is based on visibilitychange, vue-router events and other graphql queries, with some debounce and timeout. It end up between urql and graphql-sse, which makes it totally transparent for the rest of the application.

When user inactivity is detected, I use the abortController to interrupt existing connections and delay reconnection until the user come back. If the user do any query or change page, the connection will be reestablished and the subscriptions will work again.

It works but it feel a bit dirty, few methods like disconnect, connect (or pause/resume) could have be really convenient. From a dev perspective, the only method exposed is dispose but it forced me to recreate a new client every time, which doesn't play nice with urql and existing subscriptions.

[enisdenjo]

Sorry about the late reply, completely slipped my mind.

I don't think it's dirty, the only way you can abort an active fetch connection is through the AbortController. You may just wrap the createClient function in another createAbortableClient that extends the core client functionality with whatever you need - this is why the client is simple and feature-less, per se - it is a small unit of work that can be extended to whatever you want.

From a dev perspective, the only method exposed is dispose but it forced me to recreate a new client every time, which doesn't play nice with urql and existing subscriptions.

I'd recommend the same thing as above, wrap the client with another createDisposableClient that will return a single instance which you pass to urql and hook the necessary methods so that the internal client gets recreated but the exposed/returned instance stays the same. Please note that I am speaking freely from the top of my head, this might not be the way.