-
Notifications
You must be signed in to change notification settings - Fork 258
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
Don't hit registration to gather deprecation/vulnerability metadata #10865
Comments
Triage: This change is blocked on a server feature. @JonDouglas to make sure it's on the unified backlog. |
Prototype in #11483. Already on the backlog, so need to keep it assigned to Jon. |
FYI, a simpler solution may be to reconsider the registration API's paging strategy. Currently, the registration API splits package's information into groups of 64 package versions. This page size appears to be much too low. Making registration pages include more package versions would reduce the number network requests the client needs to do without needing to update the protocol or clients. See: #8058 (comment)
|
Blocked on NuGet/NuGetGallery#7297.
A lot of the feedback centered around the PM UI has to do with how sluggish and heavy the UI looks.
Some of the problems are technical decisions in the PM UI, some are UX driven, others are a little bit of both.
Say you create a new project and you open the PM UI.
0 remote calls happen because NuGet will default to the installed tab.
Switch to the browse tab.
You get 1 search call + N registration calls, where N is the number of loaded packages.
The logic behind this registration call is fetching vulnerability and deprecation information.
Registration pages can be just as large and as heavy to parse as the search ones.
This "trick" is there due to NuGet/NuGetGallery#7297.
Given the repeated feedback about the clunkiness of the PM UI, I think we should ask the server team to prioritize this ask, and we should follow up on the equivalent client side.
Alternatively, we can hack it and only fetch metadata whne nuget.org is the source. This idea is bad. Current perf is worse.
The text was updated successfully, but these errors were encountered: