Client-Side Paging for Hierarchical REST Data
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Naive paging algorithms are inefficient for hierarchical data structures, leading to performance bottlenecks when loading and displaying data in RESTful web services, as they require multiple backend requests for each node expansion, overwhelming limited client processing power.
Innovation Solution
A 'magnitude' field is introduced in hierarchical data structures to track the number of entries in sub-trees, allowing for efficient paging by calculating correct paging parameters and skipping collapsed sub-trees, reducing the workload on the client UI layer.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If naive paging algorithms are used for hierarchical data structures, then data can be loaded in sequential order, but multiple backend requests are required for each node expansion, increasing network traffic and server workload
Solution Approach 1:
The patent pre-calculates and stores magnitude values (subtree entry counts) in the hierarchical data structure before paging operations. This preliminary action enables the client to determine exactly how many entries exist in each subtree, allowing it to calculate correct paging parameters and skip collapsed subtrees without making additional backend requests, thereby reducing network traffic while maintaining efficient data loading
Solution Approach 2:
The patent transforms the hierarchical tree structure into a flattened table representation that includes magnitude values for each node. This dimensional transformation allows sequential paging operations to work efficiently on hierarchical data by treating it as a linear sequence with embedded structural information, enabling the client to navigate and page through hierarchical data without requiring multiple backend requests for each expansion
2Reliability
If all hierarchical data is loaded at once, then complete data is available for display, but it overwhelms the limited processing power of the client device
Solution Approach 1:
The patent segments the hierarchical data into manageable pages based on the flattened table structure and magnitude values. Instead of loading all data at once, the client loads only the current page of entries relevant to the visible portion of the tree, reducing the processing load on the client device while maintaining the ability to access complete hierarchical data through sequential paging operations
Solution Approach 2:
The patent implements partial loading of hierarchical data by using magnitude values to determine exactly how many entries to load in each paging operation. The client loads only the necessary number of entries for the current view rather than all possible entries, reducing client processing requirements while still providing access to the complete hierarchical structure through incremental loading
3Ease of operation
If paging parameters are calculated without magnitude information, then simple algorithms can be used, but collapsed subtrees cannot be skipped, increasing the number of backend requests
Solution Approach 1:
The patent pre-calculates magnitude values (the number of entries in each subtree) and stores them in the flattened table representation before paging operations begin. This preliminary calculation enables the client to efficiently skip collapsed subtrees by adding their magnitude values to the paging skip parameter, maintaining simple client-side paging logic while dramatically improving data loading speed by avoiding unnecessary backend requests for collapsed branches
Data Source
AI summary
In an example embodiment, an efficient paging algorithm is provided. A first request for hierarchical data is generated and sent to a backend located on a server device. A first flattened table containing hierarchical data responsive to the first request is received from the server device, the first flattened table containing a plurality of entries, each entry corresponding to a node in a sub-tree of hierarchical data responsive to the first request, and, for each of the plurality of entries, a magnitude value indicating a number of nodes underneath the node corresponding to the entry, in the sub-tree. One or more paging parameters are created based on one or more of the magnitude values. A second request for hierarchical data is generated based on the one or more paging parameters and sent to the backend. A second flattened table containing hierarchical data responsive to the second request is received.