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

Implement caching in browser / server for IPFS data #199

Open
drewcook opened this issue Oct 28, 2022 · 0 comments · May be fixed by #253
Open

Implement caching in browser / server for IPFS data #199

drewcook opened this issue Oct 28, 2022 · 0 comments · May be fixed by #253
Assignees
Labels
enhancement New feature or request

Comments

@drewcook
Copy link
Owner

Enhancement

Please fill in these details describing the enhancement or improvement you'd like to see to the existing functionality within the UI. Please be as specific as possible.

What would you like to see improved or updated?

Currently all audio music blobs that represent both full projects/nfts and individual stems are stored on IPFS. This means that any time we load a project page, the client has to ping the IPFS provider for the audio files, and then load them into the audio players so they can be previewed. This means we are relying on a centralized IPFS provider for this, which isn't 100% reliable. And files take time to be served up and found in the network, which isn't fast. This is noticeable viewing any project page as the stems don't load quickly and sometimes not at all.

Thus, we should have a redundant storage solution so these blob files are readily available and we can load almost immediately when needed. We can solve this using an in-browser Redis cache. The cache is a basically a JS object of keys/values. We should store the actual blob data as the values, and the keys should be the stemID. For a start, the cache object should have two top-level keys nfts and stems. The keys for nfts should map to the ObjectID in mongo as a start, as well as with the stems keys. Then we could easily reference the cache for these when needed.

When writing to the cache, a new item should be added at two points in the workflows:

  1. When a user uploads a new stem, after it loaded to IPFS and in mongo, it should be stored in the cache under the stems key. The key for the new item is the returned id from mongo after the record is created. The value is the blob data.
  2. When a new NFT is minted. After the NFT is combined, stored into IPFS, stored into mongo, and minted on-chain, the next step is to store the blob data for the audio of the NFT as a new item in the cache, under the nfts key. The key for the new item is the returned id from the mongodb record. The value is the blob data.
@drewcook drewcook added enhancement New feature or request new issue This issue hasn't been triaged from the core team and removed new issue This issue hasn't been triaged from the core team labels Oct 28, 2022
@0xlws 0xlws linked a pull request Dec 16, 2022 that will close this issue
12 tasks
@noahdahlman noahdahlman changed the title Implement Redis caching in browser for IPFS data Implement caching in browser for IPFS data Dec 16, 2022
@noahdahlman noahdahlman changed the title Implement caching in browser for IPFS data Implement caching in browser / server for IPFS data Dec 16, 2022
@noahdahlman noahdahlman assigned noahdahlman and unassigned drewcook and 0xlws Dec 16, 2022
@Destiny-01 Destiny-01 linked a pull request Feb 6, 2023 that will close this issue
14 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants