microsoft / bedrock

Automation for Production Kubernetes Clusters with a GitOps Workflow
MIT License
129 stars 12 forks source link

Spektate dashboard should support pagination #800

Open samiyaakhtar opened 4 years ago

samiyaakhtar commented 4 years ago

As a: developer/manager/operator

I want: to view the deployments on my dashboard split into pages

So that: the page does not take forever to load and render when there's too many deployments to show.

Describe the solution you'd like: So far, we've been displaying all the deployments in a single table view. The goal is to display n deployments at a time in a single page view:

Acceptance Criteria: Deployments dashboard supports pagination

Describe alternatives you've considered:

Additional context:

Does this require updates to documentation?:

andrebriggs commented 4 years ago
  • [ ] Think about whether data should be fetched when the user tries to view the next page, or lazy loading

@samiyaakhtar maybe we can start with this first and break out a spike task since this is XL effort

samiyaakhtar commented 4 years ago

@andrebriggs opened task https://github.com/microsoft/bedrock/issues/874

edaena commented 4 years ago

Context Azure builds expire after 2 weeks SPK shows builds of the last 2 weeks Azure Storage API: returns a max of 1000 items at once, may execute for a max of 5 seconds

Objectives Rendering long lists freezes the UI Improve readability/usability Infinite scrolling, lazy loading table

Approaches
Client-Side Pagination Load all deployments in the background as the page loads but displaying them in multiple pages. This helps the filters work across all the deployments since filtering can be client-side. Pros: Leverage existing front-end sorting and other existing front-end logic Fast load time between pages Fast filtering Cons: It will not scale with significantly more data because it will have to be fetched all at once.

Azure-Storage Pagination API Load deployments by page (get azure table results by page) and filtering should fetch results from server-side Pros: Leverage the Azure Storage pagination API Data is not fetched all at once Cons: Azure Storage Table doesn't support order by for sorting New custom logic to sort/filter across the data and fetch the given page Network requests upon navigating between pages Estimated longer time to implement compared to the client-side approach

Conclusion Client-side pagination is sufficient for the SPK use case given the context and objectives listed above.

andrebriggs commented 4 years ago

UI should indicate that there are several pages available to view

@samiyaakhtar given the idea of "infinity scrolling" is this still accurate?

andrebriggs commented 4 years ago

One idea is that we limit data to N rows then we provide a search functionality for anything more than that. This way we can create a different operation for queries that users have. This will be much simpler than attempting to manage pages or infinite scrolling. cc @jred55 @gemorris @samiyaakhtar

gemorris commented 4 years ago

Another strategy could be implementing a "default filter" e.g. when the page loads it is by default filtered to the last N days, and the user could then choose to remove that filter (and have a slower load time)

gemorris commented 4 years ago

After discussion in the weekly meeting I think the best strategy is to by default load N rows (likely 50) and then below the last row, add an additional row with different styling that says "Currently only viewing the first N rows, click here to load all rows"