Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimize User Reputation Fetching #2781

Closed
rdig opened this issue Oct 11, 2021 · 0 comments · Fixed by #2809
Closed

Optimize User Reputation Fetching #2781

rdig opened this issue Oct 11, 2021 · 0 comments · Fixed by #2809
Assignees

Comments

@rdig
Copy link
Member

rdig commented Oct 11, 2021

The way current reputation oracle works is that when you make a request to getReputation, behind the scenes, it not only fetches the current user's reputation value, but also the proofs (key, branchMask, siblings, ...) for which it needs to load and process the whole reputation state, which is a heavy operation.

Currently we do the above for all places we need the reputation, both for display (where we don't actually need proofs) and both for sending a transaction (where we do).

To optimize this, and ensure the reputation, at least for display purposes loads faster (a lot of dapp hang time currently is because of the reputation orancle endpoint being slow), Alex introduced a new enpoint for the reputation miner, which just returns the value we need to display, without the proofs.

I'll integrate that into colonyJS, most likely as getReputationLight or getReputationValue, and then this issue needs to refactor the current reputation display in the dapp.

Components will use the new "light" reputation display (well, i guess this goes in the resolver actually...).

Sagas will still use the old, "heavy" way of fetching the reputation since in there we also require the proofs.

I'll leave a comment in here after I've built the new client, and that this can be tackled.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant