osmosis-frontend
osmosis-frontend copied to clipboard
osmosis-labs
Add client side node balancing
Currently when I refresh my assets page, all assets are initially at 0 in default order. Then when the response is obtained from the server + wildly resorted based on the assets i have.
It would be ideal if we could at least have the assets I have, be kept in local storage during refreshes. Waiting for the numbers to fill in at least feels more natural, but the sort order vastly changing is odd.
This may add a lot of complexity to maintain. IMO, we should work on adding more/better query nodes so data loads sooner.
@pyramation and I have been in talks of some sort of FE js lib to load balance traffic to available and performant nodes, or, less preferably, sending requests to a proxy load balancer service.
@sunnya97 and I have also remembered prev convos of copying an Eth package (don't remember the name) that executes this well. (I believe on the browser/client)
The FallbackProvider in ethers.js
https://docs.ethers.io/v5/api/providers/other/#FallbackProvider
Perhaps, we can go further and not fallback to a provider, but generate an ideal provider for the client. Perhaps based on proximity, load, etc.
tracking in telescope as well https://github.com/osmosis-labs/telescope/issues/167
maybe not relevant to this issue in context for FE, but for backend proxy, https://github.com/eco-stake/cosmos-directory is open source and @tombeynon mentioned we could deploy a server with cosmos-directory on it
There are pros and cons to both approaches. But IMO I lean toward a client-side solution since it would be more decentralized and would also mean less infra to maintain.
Another option could be using an API like https://status.cosmos.directory/osmosis to enhance your client side load balancing, that's essentially the data the proxy uses to load balance. That API is public/open source, but it's pretty trivial to implement manually if preferred.
CORS was the other reason I moved to a proxy instead of client side load balancing, but I'm relying on chain registry nodes for REStake so have less control of that side of things.
a hybrid approach could be to do client-side loadbalancing with keplr endpoint as the osmosis-fe main endpoint, and then we can fallback to cosmos.directory. This gives us best of both frontend and backend load balancing.
If we did that, we'd likely want to test out how much traffic we'd anticipate sending to @tombeynon's server and if we should host our own cosmos.directory on osmosis infra.