Review performance of application inventory page

[sjd78]

Background

On both 0.7 and main branches, there was logic attached to the useFetchApplications() hook to try to minimize the amount of time the query refreshes. The query can be quite heavy when there are a lot of applications in the hub. However, the logic wasn't always effective at limiting the refreshes (in a sufficiently large system a task could always be active and keeping the refresh always active) and/or making sure the current data is displayed (turning off a refresh before an update is captured). PR #2346 removes the logic in favor of keeping the refresh rolling.

Summary

Evaluate the performance of the useFetchApplications() query in practical use. Things to look at:

• Request/response time to the hub
• Memory consumption on the hub
• Size of the response in transit
• Time taken to process the response and have the data push to the components
• Memory use in the browser

Potential Solutions

Based on the performance testing, a few solutions could be pursued:

• Have a report endpoint added to the hub to return a minimum of information needed to drive the table. Then use the report endpoint query and adjust data use throughout the various application views. This could minimize the query, transit and parsing times and keep the memory consumption light.
• Adopt hub pagination, filtering and sorting. This would also need to support bulk operations that apply to ALL applications in a filtered group and not just what can be seen on a page.
• Note: More exotic solution are always possible (such as a query gateway to only include fields required as part of the express server) but keeping those at a minimum is always preferred.

Note: This issue is a follow up to #2346

[konveyor-ci-bot]

This issue is currently awaiting triage.
If contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.
The triage/accepted label can be added by org members.