Retry on fatal closure best practices

[tylerschoppe]

Hi! I've seen in the docs / issues that retries will be limited to codes that are considered to be non fatal. Given those rules I was wondering what you all would suggest for retrying in the event that a JWT has expired and the socket is closed with 4400? The recipe for graceful restart seems like a good starting place but I'm working on a project where the token refresh is fairly quick and it seems overkill to be constantly reconnecting. Curious what would be the best practice or if an existing pattern to cover this scenario already exists!

Thanks a lot!

[enisdenjo]

Alternatively you can use the GraphQL over WebSocket Protocol pings and pongs to transmit the refresh token. This way you would keep pinging the server from the client with the necessary credentials in the payload, the server would validate each ping's credentials and proceed accordingly (if valid noop, if invalid close connection).

Recipes "Client usage with manual pings and pongs" and "Server usage with ws and subprotocol pings and pongs" should help you get started.

[tylerschoppe]

Love that idea but sadly I don't have control over the server implementation, working with Hasura, so it sounds as if graceful restart might be the way to go even if it's a bit heavy handed!

[enisdenjo]

Sorry to hear that, graphql-ws tries to cover most of use-cases with the built-ins (in use/*) and intentionally does not cover everything to avoid unnecessary technical debt.

To remedy this, graphql-ws offers a makeServer for setting up your own server with absolute control.

[tylerschoppe]

Totally understand the rationale! Appreciate the insight and quick responses!