Closed bgrainger closed 4 years ago
Cool!
So truth be told, I did that because I was worried about performance. But I think that’s when I didn’t have lazy loading of packages. I’m assuming performance is still good with this? Are there any packages in particular I should test out?
Good question; I didn't test that.
serilog (https://www.fuget.org/packages/serilog/) has 341 package versions. (I think, but don't know for sure, that this is on the high end for typical NuGet packages.) Testing locally, this code loaded six pages of results in ~1.45s, so about 250ms per page. The HTTP requests to the NuGet API were about 65ms each. If the rest of the time was parsing and loading the results, there may be scope for optimisation in FuGetGallery. (I haven't profiled it in detail.)
Some more packages with 1000+ versions:
Given what @loic-sharma said, maybe we should limit this to a couple pages. I don't see the utility of a UI presenting 1000 versions.
Just curious, why are you using the package metadata (registration) API to get the list of versions? FYI, you can also get the list of versions using the package content (flat container) API or the autocomplete API:
I don't know any specific reason other than ignorance. In my defense, "Autocomplete" is not an API name I'd associate with version listings. ;-)
Thanks for the tips! I'll add this when switching over to service provider lookups.
In my defense, "Autocomplete" is not an API name I'd associate with version listings. ;-)
Autocomplete can do both autocomplete on package IDs and enumerate listed versions. I agree it's really confusing 😂
@loic-sharma I'm not able to use either of the APIs you mentioned because neither provides date information for the versions (I display their publish date in the UI).
Fixes #95.
When the NuGet API returns package versions as part of the response, the code only read the versions from the last page. It now reads the versions from all pages, whether they're returned inline or referenced via a secondary URL.