Rationale for Returning NFTs Map in Non-Pageable Response

[AdonousTech]

Most of the API calls with potentially voluminous results are pageable via LastPostHashHex. However, the GetNFTsForUser route returns an "NFTsMap" as a single object. This object can be huge, depending on the NFT project. Consequently, this particular data structure does not seem well-suited for long-term scalability.

I think we should return an array of NFTsMap that is pageable in the response. That way, we can page the results by passing in the LastPostHashHex, similar to other calls.

Otherwise, devs are forced to use GetPostsForUser route and "filter" the posts to NFTs. This causes a F/E performance hit, because we are making unnecessary calls, and TTFP (time-to-first-paint) suffers as well.

UPDATE - Also, the IsForSale boolean value is basically ignored. When the value is set to null, it should return all NFTs for a public key, regardless of the IsForSale status. However, this does not work properly, as only NFTs with IsForSale = true are returned.

Thoughts?

https://github.com/deso-protocol/frontend/blob/d98a71502851b4a22f1fc251597f8c700145a14d/src/app/backend-api.service.ts#L980

[maebeam]

Yes, this endpoint needs to be paginated. Contributions welcomed!

[AdonousTech]

Ok. I need to dive into GO, then I'll be making more contribs to the backend!