You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
The text was updated successfully, but these errors were encountered:
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
andstems
. The keys fornfts
should map to the ObjectID in mongo as a start, as well as with thestems
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:
stems
key. The key for the new item is the returnedid
from mongo after the record is created. The value is the blob data.nfts
key. The key for the new item is the returnedid
from the mongodb record. The value is the blob data.The text was updated successfully, but these errors were encountered: