Adding cumulative rewards and losses to api

[ajinkyaraj-23]

• [api] add baker's total staking rewards and losses

• rewards staked
• rewards earned
• losses applied on its own stake
• losses applied on its own unstaked balance

• [api] add staker's total staking rewards and losses

• rewards staked
• losses applied on its stake
• losses applied on its unstaked balance

[Groxan]

Hi!

JFYI: it would be great if you provided some details on what has been done and why you think it should be merged into the main repo, i.e. how your changes benefit all users. Also would be great if you explained your approach and especially its effectiveness and performance. All these would help us review your PR.

Anyway, here is my feedback.

1. You added computed props to the BakerRewards model.

Such computed props is not something that we are happy about, because it is a very app-specific thing that is usually aimed to benefit just a single client who wants to move his business logic from his side to the API side. For example, you have added TotalStakedRewards. In your app by "total" you understand everything but shared rewards. But in our apps by "total" we understand all rewards, including shared. So, if we add our computed prop, we won't benefit your app. If we add your computed prop, we won't benefit our apps. Or if we add computed props for all possible use cases, we will simply overload the API model and make it very confusing (I'm not even talking about redundant computations and network traffic).

Therefore, in long term it's better if API clients build custom computed props on their side, instead of moving their business logic to the common API. So, please, try to avoid computed props.

2. You tried to calculate staking rewards for stakers and add it to the DelegatorRewards model.

Unfortunately, your approach is wrong by design. Staking rewards and delegation rewards are incompatible entities. Delegation rewards are linked to baking rights and therefore delayed/shifted by several cycles, while staking rewards are real-time and not linked to anything. For example, when a staker starts staking, delegation rewards entity simply doesn't exist yet, so you will miss part of the staking rewards data. This contradicts our data quality requirements.

Therefore, a different approach is needed for handling staking rewards.