### **Problem Statement** Right now, we show **subgroups** and **projects** together on one page in [**Security Inventory**](https://gitlab.com/groups/gitlab-org/-/security/inventory), but: * They come from **two separate GraphQL connections**: * `group.descendantGroups` * `group.projects` * Each has its **own cursor-based pagination** (`pageInfo.after`, `before`, `endCursor`). The frontend merges both lists and handles paging manually. This causes several issues: * Complex state management (traversing two cursors, and maintaining their states). * Difficult to keep a consistent page size * Back navigation (`before` pagination) is technically possible but unreliable. * Future implementation of sorting / filtering may increase complexity #### **Proposal** Move pagination and merging logic to the **backend** by introducing a new GraphQL field: `group {`\ ` subgroupsAndProjects(first: Int, after: String, before: String): GroupItemsConnection!`\ `}` This field would: * Fetch both descendant groups and projects internally. * Return them in order: **all groups first**, then **projects**. * Use a single **unified cursor** (`pageInfo` with one `endCursor`, `hasNextPage`, `hasPreviousPage`). * Maintain a stable page size and consistent pagination boundaries. --- #### **References** GitLab supports both cursor-based pagination and offset-based pagination through GraphQL - prefers cursor-based * https://docs.gitlab.com/development/graphql_guide/pagination/ * https://docs.gitlab.com/development/database/pagination_guidelines/ --- #### **Next Steps** * Confirm feasibility of new `subgroupsAndProjects` resolver. * Implement and test pagination in both directions. * Update frontend to use new single connection. * Remove frontend merge and “Load more” workaround.