Balances page fails to load (rate limits)

[ghost]

I did some investigation into the Balances page, which is always broken for me and slams the RPC node until it rate limits you.

Problem: A single load of the "Balances" page from my main wallet, hit the projectserum public rpc node about 400 times in 2 seconds before getting rate limited. These are 95% individual calls to getAccountInfo, should be replaced with getMultipleAccounts asap. It actually hit ~600 requests in the total page load, but the limiting started at ~400 in 2s.

Addressing this could, in my opinion, immensely improve UX. And maybe reduce load on projectserum rpc's by an order of magnitude. The orders page has similar behavior.

Potential solution: Batch all these single getAccountInfo calls from the Balances page into multiple getMultipleAccounts calls, instead.

[ghost]

Discussed with someone who took a look (@cryptogosu) - apparently solana's web3.js doesn't have getMultipleAccounts directly implemented.

However, was told the following: You can do connection._rpcRequest to use any endpoint not built in on the solana web3js

So this should still be doable.

[armaniferrante]

Discussed with someone who took a look (@cryptogosu) - apparently solana's web3.js doesn't have getMultipleAccounts directly implemented.

However, was told the following: You can do connection._rpcRequest to use any endpoint not built in on the solana web3js

So this should still be doable.

If you're lazy, Anchor also has this via anchor.utils.rpc.getMultipleAccounts. So one could either use that or copy pasta the implementation from there.

[jacobcreech]

Looks like

Discussed with someone who took a look (@cryptogosu) - apparently solana's web3.js doesn't have getMultipleAccounts directly implemented. However, was told the following: You can do connection._rpcRequest to use any endpoint not built in on the solana web3js So this should still be doable.

If you're lazy, Anchor also has this via anchor.utils.rpc.getMultipleAccounts. So one could either use that or copy pasta the implementation from there.

Found an actual implementation already here https://github.com/project-serum/serum-dex-ui/blob/master/src/utils/send.tsx#L931

Working on this, should be pretty simple. Problem is, I keep getting rate limited during testing 🤷

[jacobcreech]

Updated Balances page to use getMultipleAccounts. However, I'm still seeing a lot of getAccountInfo calls from something else on the page, even before I connect my wallet. I will investigate to understand and mitigate. For now, I will open the PR because getMultipleAccounts should at least lower the amount of calls.

https://github.com/cryptogosu/serum-dex-ui/commit/a595edf15c5ccd9f5ebf4d33828ec3a6599fa3ac

[ghost]

Dug very deep.

These lines (https://github.com/project-serum/serum-dex-ui/blob/master/src/utils/markets.tsx#L48-L70) need to be modified to use getMultipleAccounts, then deserialize into the Market object from serum-ts.

Or, if we can only deserialize the Market struct using serum-ts, would need a helper method in there to do the mass call and deserialize each, returning into the Collection

[ghost]

@cryptogosu Tested the latest changes. The load seems to work good, but the rows in the table are re-arranging themselves every few seconds in seems.

[jacobcreech]

@skynetcapital Added ordering of balances by descending order so that order is guaranteed. Whenever the page re-renders, it will go grab the mints/accounts, which are not guaranteed to be in the same order. This should fix the balances switching on every render

[ghost]

@cryptogosu Awesome, the sorting seems to have fixed it. @armaniferrante should be good for another QA to review