Performance question
At my company, we have a few different blockers for data fetching - we use our own internal package manager and “repackage” external ones if approved by infra. We use Apollo (older version) and a wrapped Apollo for rest endpoints. My team “vendored” react query because we had specific use cases that required the granular control it gives and decided to stick with it.
My question is, I know Apollo eats at performance over time calling their hooks (at least in the version we use). Does react query have the same issue depending on the observers? Or when would it make sense to pass the data as props vs calling the hooks we create to manage the fetching?
We have some places where the query options would change, specifically the select option, but we already suffer from perf issues in our app we’re trying to resolve, and as I’m rearchitecting our component structure I want to make sure I’m not adding a “death by 1000 cuts” scenario 🙂
4 Replies
deep-jade•4w ago
when you get into more than 1k queries, our biggest perf problem is timers that get started (for staleTime and gcTime). At that point, you'd want to pass your own
timeoutProvider to our timeoutManager so that you can control that. A timer wheel (https://www.npmjs.com/package/timer-wheel) is then usually a good implementation to decrease the number of setTimeout calls.
This feature was recently contributed by an engineer who pocs react-query at notion. Their target is 15k queries.xenial-blackOP•4w ago
Awesome! Thank you.
Sorry if this is a dumb question, when you say queries, are you including subscribers to a query, that would get registered as listeners in the query cache? Or are you meaning 1k actual requests?
deep-jade•4w ago
GcTimers are per query, but staleTime timers are per observer
Also if you have large data, structuralSharing can become an overhead but usually the benefits outweigh that because it reduces rendering. Might not be necessary with react compiler though
xenial-blackOP•4w ago
thanks so much! appreciate the insights.