Best practices for structuring query keys when fetching batched data

[lisherwin]

Hi!

What is the best option for structuring query keys to cache batched data returned from endpoints? For example, we might have an endpoint like /prices?tickers=AAPL,GOOG,AMZN,... that will return a list of all prices for a provided set of stock tickers. We'd like to share this pricing data across all components that may require any subset of these stock prices.

I have come across the following ideas, but they seem to have their own limitations.

1. Have a query key for every element we've fetched for.
   • Ex: ["prices", "AAPL"], ["prices", "GOOG"], ["prices", "AMZN"]...
   • We are concerned that the number of query keys can grow unboundedly and the performance implications of this, as we do have users who may have tens of thousands of unique items to fetch for. We would also introduce logic in our queryFn to invalidate every one of these query keys, which sounds expensive, especially considering that we're polling on this endpoint in certain cases.
2. Have one query key that simply holds a map of the items that we're fetching for, and have call sites pass a select function into the query hook.
   • Ex: ["prices"] where the value is something like {"AAPL": 144.29, "GOOG": 99.87, "AMZN": 103.13}.
   • The downside we saw here is that we're unable to partially invalidate subsets of prices. For ex, if we later fetched for just "AAPL", we would getQueryData for the whole map, update the entry with key = "AAPL", and invalidate ["prices"], which would re-render all active queries on the prices query hook. I've also read that excessive use of select across many components can hinder performance.
3. Have a query key for each permutation of batch price fetches that we do.
   • Ex: ["prices", { tickers: ["AAPL", "GOOG", "AMZN"] }]
   • Our concern here is that a screen that fetches for a subset of these items (say ["prices", { tickers: ["AAPL"] }]) will not load already cached data from RQ and we would introduce a query key for potentially every permutation of items we could fetch for (even more unbounded than approach 1).
   • This is actually our current approach because it seemed the most "correct" in that our queryKey most accurately matched the dependencies of our queryFn. However, we realized that data was not being shared across components that fetched for a different subset of items, since it doesn't seem like there's a way for RQ to tell that there's overlap in the queryKey.
4. We looked into notifyManager.batch but was unclear if/how this would help with this problem and there seemed to be limited documentation on this.

Any advice would help here, since we're not sure if we overlooked any obvious APIs or solutions. I'm more than happy to provide a code sandbox for these solutions, but I am thinking that this is fairly self-explanatory without code. Thank you in advance for all your help!

[Fallup]

Hey @lisherwin, how did you solve this in the end? If you don't mind sharing. I'm currently trying to solve the same thing

[jamesleeht]

Thanks for the post. For our situation we decided to go with option 2 since we only needed to select one at a time. I think for more complex situations https://github.com/yornaath/batshit might be worth considering.