hooks not working after unmouting component

[ejkkan]

Hey! First off, love the lib, really helped me out not having to write this client from scratch!

One usecase that is not working for me though.

I'm using "useSubscription" in a component on a route i only show for a logged in user.
If I log the user out, hence they leave the logged in route for a "login" route, and then go back to the logged in route again.
There scenarios takes place:

1. If I don't close the, it is stuck in readyState 3 when I get back.
2. If i close the client and the come back, it never opens up again.

Part is because the hook needs the prepared query instantly at runtime, so you have to create the client outside the react function. So if you close it, it just never opens a new one.

My solution for now was just to skip the hook and use it like:
wsClient.subscribe(callback, query, {});
and overwrite my cached values instead

[kigiri]

Hello @ejkkan Sorry I had not seen the issue, If my understanding is correct, it would be to be able to resume the websocket connection.

This make sense, overall loss of connection of the websocket is not really supported by hasura-ws, on our production app we just reload show an error with a button to reload the whole app if connection is lost and login / logout will do a full reload too.

Just curious, are you still using this library or did you move to a more popular lib like appolo or URQL ?

Overall we had a bunch of issues with performances in hasura graphql subscriptions which was one of the main reasons we picked hasura in the first place, we are still using and supporting this client but I'm not sure I would use it for future products

[ejkkan]

Hey @kigiri

Interesting to hear!
I ended up writing my own implementstion later on.

I'd be really interested to hear about your performance issues with hasura. I've yet to see them so any learnings would be greatly appreciated!

[kigiri]

Sure @ejkkan ! Here what happend to us:

It was a bit of multiple issues that came together:

• Over use of Views for "conveniance" to make the graphql looks more natural, this made queries heavier overall
• Graphql allows to very easily do complex joins and as such you can write pretty heavy queries without really realizing
• Subscription implementation is fairly costly in ressources, it's a simple polling on a .5s timer.

So, we had, complex queries, joining over multiple views getting spam every .5s by each of our active users, once we had about 300 active users our server was already starting to sweat.

The way we solved it:

• Avoid using views (we partly replaced some view logic with db triggers that would update a real table, maybe materialized views could have worked too)
• Being more mindfull with our joins and ensuring we have the proper indexes setup in pg
• Break down the subscription in 2:
  • only subscribe to "updated_at" column or equivalent
  • retrigger the "costly" query once this was changed
  • Use alternatives to subscribes when ever we can (retrigger the query after mutations, etc...)

Is your implementation opensource ?