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

Read all pages of a package's results #101

Merged
merged 1 commit into from Jul 9, 2020

Conversation

bgrainger
Copy link
Contributor

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.

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.
@praeclarum
Copy link
Owner

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?

@bgrainger
Copy link
Contributor Author

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.)

@loic-sharma
Copy link
Contributor

Some more packages with 1000+ versions:

@praeclarum
Copy link
Owner

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.

@loic-sharma
Copy link
Contributor

loic-sharma commented Mar 3, 2020

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:

@praeclarum
Copy link
Owner

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.

@loic-sharma
Copy link
Contributor

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 😂

@praeclarum praeclarum merged commit 4c4e95d into praeclarum:master Jul 9, 2020
@praeclarum
Copy link
Owner

@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).

@bgrainger bgrainger deleted the read-all-results branch July 10, 2020 15:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

MySql.Data missing latest version, not showing old versions
3 participants