Staking Rewards Viewer Open Grant Application

[jackson-harris-iii]

Grant Application Checklist

• The application template has been copied, renamed ( project_name.md) and updated.
• A BTC or Ethereum (DAI) address for the payment of the milestones is provided inside the application.
• I have read and acknowledged the Terms and Conditions.
• The software delivered for this grant will be released under an open-source license specified in the application.
• The total funding amount of the project is below USD $30k for initial grant applications and $100k for follow-up grants.
• The initial PR contains only one commit (squash if needed before submitting your PR).
• The grant will only be announced once the first milestone has been accepted.

[CLAassistant]

All committers have signed the CLA.

[Noc2]

Just a reminder: It looks like you still have to sign the CLA. I also just added your app already here: https://github.com/jackson-harris-iii/staking-rewards-viewer It looks nice. Great work. I have a few additional questions regarding the application itself:

• What is the purpose of the back end (speed up the data access)? How do you plan to scale the project or to deploy the back-end on ipfs? Deploying a "real" back-end on ipfs means you can not easily store a lot of data there and it usually causes a lot of problems (data isn’t pinned, etc.). Also this way you can not store any private keys etc. in the backend, because anything is publicly accessible. I imagine it will be hard to scale the project/improve the usability at this stage, if everything is deployed on ipfs.
• Regarding the application, I think it makes sense to combine milestone 1 and 2 at this stage.
• Could you add the deliveries 0a - 0d to your milestone, see https://github.com/w3f/Open-Grants-Program/blob/master/applications/application-template.md#milestone-1-example--implement-substrate-modules

[jackson-harris-iii]

@Noc2 Thanks for adding that for me. I've updated the milestones and added the deliveries as well.

• There won't be a "back-end" any longer. The code for the original collector has been refactored into utility functions.
• Enabling a user direct download from their browser will not require a server. Similar to the original collector we will create a CSV file for the user in the browser that they can download. I am currently exploring how to do something similar in JSON format. (I might just open a new tab with the JSON in it if there is no better alternative.)
• As for IPFS if we remove the need for a server. Fleek allows for NEXT.js applications to run on IPFS https://blog.fleek.co/posts/fleek-nextJS.

[mmagician]

There won't be a "back-end" any longer. The code for the original collector has been refactored into utility functions.

@jackson-harris-iii So just to double check that I understand correctly: does that mean you're not planning to use the code from the staking rewards collector anymore?

[jackson-harris-iii]

There won't be a "back-end" any longer. The code for the original collector has been refactored into utility functions.

@jackson-harris-iii So just to double check that I understand correctly: does that mean you're not planning to use the code from the staking rewards collector anymore?

@mmagician currently the staking rewards collector code is located in the src/utilities folder of staking rewards viewer and is the core for the data retrieval, results shaping, and csv creation.

There is some refactoring being done so that it can work solely in a browser. I could use it 100% as is, if required, but that would remove the possibility of being entirely on ipfs. The original collector relies in a few nodejs modules, but since it's all JavaScript that are alternatives I can use to make it all work client side.

[mmagician]

The ideal scenario, IMO, is code reuse. There are likely going to be updates to the original collector code (either extra features, or just keeping up to date with polkadot APIs) and it would be great if your frontend supported these changes out-of-the-box (perhaps have it as a sub-module? or reference it as an npm package?)

Do you foresee a scenario for this grant where part of the work would be refactoring the original tool s.t. it supports both the CLI and your use case better? Perhaps you could have a chat with @jonasW3F to see if you'd align on the outcomes (he's also very much interested in the frontend, btw).

[Noc2]

@jackson-harris-iii Sounds good to me. Could you update the PR? I think the application still contains for example: “Back End: Next.js/Vercel/IPFS”

[jonasW3F]

I would also prefer that both versions stay synced and that the CLI version stays functional. Currently, there are no immediate updates planned, but that can always change. I am not a programmer, so I cannot judge the quality of my code but certainly, it could be improved and refactored. So, I would be open to include PRs from @jackson-harris-iii, which make the code functional for the front-end and leave the CLI version intact.

[jackson-harris-iii]

I would also prefer that both versions stay synced and that the CLI version stays functional. Currently, there are no immediate updates planned, but that can always change. I am not a programmer, so I cannot judge the quality of my code but certainly, it could be improved and refactored. So, I would be open to include PRs from @jackson-harris-iii, which make the code functional for the front-end and leave the CLI version intact.

Hi @jonasW3F , After reviewing your comments I have given some thought on how I think we can proceed with keeping the two repos synced. Here are my notes on accomplishing that.

• The CLI version requires node.js, it will not function in the browser. A browser-only version would be required in order to use IPFS for the entire application.
• Using vercel, an ec2, or some other server we could host a version that keeps the CLI and front-end tool using the same code base. (vercel has generous free-tier (hobby) rate limits.)
• If we have a hosted version the front-end could be accessible via IPFS, but it would always require a connection to a hosted server if the CLI version and front-end tool are coupled together. We could use Fleek for this. (More exploration will be required)
• As for keeping the two versions synced my thoughts are that it would require an input to let the tool know which environment is making the request. This could be added to the config file and submissions from the front-end. The front end can also create the csv or json download on demand so the files are generated on the client-side instead of each time the tool is used. (This removes any potential storage management and reduces bandwidth usage.)
  -Once the modifications are made to the original repo, the front end could require it as a dependency. This would allow CLI users access without requiring the front-end and the front-end would remain coupled with the original repo.

[Noc2]

@jackson-harris-iii, I personally think that it’s not mandatory to keep both in sync. Potentially you can reuse some of the code and create a package for it, so it’s easier to maintain it for both solutions, but it ultimately depends on what you plan to do (and I’m not sure there is a lot of overlap). If you create a back-end, I think it definitely would make sense to also create your own database for performance reasons and no longer to rely on querying public end-points for free. For example, if you have the CLI version deployed on ipfs and a lot of users access this version via the same ipfs server, the public endpoints will quickly limit the access via this ipfs server and it stops working.

[jackson-harris-iii]

@jackson-harris-iii, I personally think that it’s not mandatory to keep both in sync. Potentially you can reuse some of the code and create a package for it, so it’s easier to maintain it for both solutions, but it ultimately depends on what you plan to do (and I’m not sure there is a lot of overlap). If you create a back-end, I think it definitely would make sense to also create your own database for performance reasons and no longer to rely on querying public end-points for free. For example, if you have the CLI version deployed on ipfs and a lot of users access this version via the same ipfs server, the public endpoints will quickly limit the access via this ipfs server and it stops working.

@Noc2 My current understanding is that IPFS would only host the tool and possibly the site. The CLI would need to be downloaded locally and run from the user's machine, the same is true for the front-end.

• As for maintainability, as it stands it would be easier and less prone to error if the two were to be separate. As for performance a lightweight virtually static front end using the public Coingecko API would be the most performant. The Coin Gecko API hasmany projects in the space using it. The calls to the API would be made from each client (both CLI and front-end). This would allow for every user to make up to 100 requests per minute from their browser or command line.

• As for building out a database, backend, and systems to support it I'd say that is getting a bit out of scope for the current proposal. However, I believe it is not needed. The most cost-effective, performant, secure, and highly available architecture would be using a static site generator and serverless allowing the individual clients to handle queries to the Coingecko API.

• I updated the proposal to say the Back end is N/A because it is using a serverless architecture

[Noc2]

@jackson-harris-iii Thanks for the update. Could you still add the deliveries 0a - 0d to your milestone, see and potentially combine milestone 1 and 2?

[jackson-harris-iii]

@Noc2 I added the additional deliveries to the proposal.

[Noc2]

@Noc2 I added the additional deliveries to the proposal.

Thanks. But now milestone 1 doesn’t contain any deliveries. Could you update the PR again?

[mmagician]

Looks good to me 👍🏼

[jackson-harris-iii]

@Noc2 I added the additional deliveries to the proposal.

Thanks. But now milestone 1 doesn’t contain any deliveries. Could you update the PR again?

Sorry about that, hadn't had my tea yet, changes made! I also moved the IPFS to future plans. There are a few different ways to go about it, and some of the specifics I'd like to discuss once we have a live version. (Account ownership, pinning, etc.)

[github-actions]

Congratulations! As part of the Open Grants Program, we want to help winning teams acknowledge their grants publicly. To that end, we’ve created a badge for projects that successfully delivered their first milestone. Please observe the foundation’s guidelines when making any announcements; in particular, don’t announce the grant publicly before you've completed at least the first milestone of the project.

At that point, we will be happy to collaborate on an announcement about the work you’re doing. Please get in touch with us at grantspr@web3.foundation in case you're interested (at least two weeks notice is preferred).

[alxs]

@jackson-harris-iii I now realise the application still contains two milestones. Didn't you mean to merge them into one in your last update? As @Noc2 mentioned, this would also be preferable for us. Ideally you'd deliver the tests with the application, and you can integrate feedback during the delivery process. Other than that, looks good to me!