jonator
commented
2 months ago WDYM by blocking? The queries are dependent on the mounting of the component tree, which may have some serial properties but I'm not quite sure how the guts of the React engine layout the tree initially. Further, a pitfall of building a dapp is often you need to wait to get the user address from the wallet (which may be blocked on installing wallet client code) which often triggers a flurry of blocked queries once we get that address. In web2, we can normally get that user identifier on the initial query from a browser cookie. Perhaps that's what you're seeing? I'm spitballing and any other input would be appreciated here.
For expensive queries, we tell tRPC not to batch them with other tRPC queries (like you see with the last query, assets.getUserMarketAsset,assets.getAssetHistoricalPrice,assets.getUserAsset). So, expensive queries operate independently and should not be blocked or block any other queries.
The "idea" with batching is it justifies small cheap tRPC queries by automatically combining them at runtime and reducing total networking overhead. But, I'm not sure the observed performance benefits are there. I'd like to verify that it runs the batch in parallel in the server as well, it should. But, it could just be the multi region & edge problem.
MaxMillington
On the pools page, I see the following two queries taking a long time (180-200ms), and appear to be blocking more queries that are required for page stability.
Slow queries:
These queries come after other queries on this page such as:
These slow queries block the following (much slower) queries, however there is no dependence and they should be parallelized:
https://app.osmosis.zone/api/edge-trpc-assets/assets.getUserMarketAsset,assets.getAssetHistoricalPrice,assets.getUserAsset?batch=1-- (850ms) on input:{"0":{"json":{"findMinDenomOrSymbol":"OSMO"}},"1":{"json":{"coinDenom":"OSMO","timeFrame":"1D"}},"2":{"json":{"findMinDenomOrSymbol":"OSMO","userOsmoAddress":"{USER_ADDRESS}"}}}