Extracted from #1713
Fetching all remote pins will become very expensive over time, we should stop doing that ASAP
(this is a blocker for shipping ipfs/ipfs-gui#91 💔)
Problem descriptions
Right now we fetch all remote pins via pin.remote.ls once, and then check cache while browsing Files.
What if user has 1k of remote pins, or more? It will take multiple seconds/minutes to before webui can show remote pin status for the first time, and the entire list will have to be re-fetched after page reload.
This is a problem because it introduces unnecessary traffic/cost for services like Pinata.
They expect us to be smart and check specific CIDs and respect their bandwidth/cpu time.
How to fix
We should build cache of remote pins progressively, checking only specific CIDs in the current directory.
API allows fetching status for up to 10 cids per request: pin.remote.ls({service: 'foo', cid: [cid1, cid2, ... cid10]})
Fetching all remote pins will become very expensive over time, we should stop doing that ASAP
(this is a blocker for shipping ipfs/ipfs-gui#91 💔)
Problem descriptions
Right now we fetch all remote pins via
pin.remote.lsonce, and then check cache while browsing Files.What if user has 1k of remote pins, or more? It will take multiple seconds/minutes to before webui can show remote pin status for the first time, and the entire list will have to be re-fetched after page reload.
This is a problem because it introduces unnecessary traffic/cost for services like Pinata.
They expect us to be smart and check specific CIDs and respect their bandwidth/cpu time.
How to fix
We should build cache of remote pins progressively, checking only specific CIDs in the current directory.
API allows fetching status for up to 10 cids per request:
pin.remote.ls({service: 'foo', cid: [cid1, cid2, ... cid10]})