GitLab GraphQL follow-up: inventory remaining REST calls and prioritize entry loading

Following up on @martinjagodic's request in #6034. I checked the GitLab backend at a35d0fdaeba0dda9436d7941130ed4911353821b and listed the REST calls that still run with use_graphql: true.

The existing GraphQL path covers listAllFilesGraphQL and batched file content/last-commit reads through readFilesGraphQL. It does not replace every entry-loading or editorial workflow request.

Remaining REST reads

Paths below are relative to api_root; :id is the encoded project path.

Operation	REST path	Current caller
Current user and project permissions	GET /user, GET /projects/:id	user, hasWriteAccess
Paginated collection entries	GET/HEAD /projects/:id/repository/tree	listFiles, cursor traversal
Single-entry/file content, including LFS downloads	GET /projects/:id/repository/files/:path/raw	readFile
File author and update time outside the batch GraphQL path	GET /projects/:id/repository/commits?path=...&ref_name=...	readFileMetadata
Branch details and permissions	GET /projects/:id/repository/branches/:branch	getBranch, getDefaultBranch
File existence and blob ID	HEAD /projects/:id/repository/files/:path?ref=...	isFileExists, getFileId
Changes between refs	GET /projects/:id/repository/compare	getDifferences
Branch membership of a commit	GET /projects/:id/repository/commits/:sha/refs	isShaExistsInBranch
Editorial merge requests and rebase status	GET /projects/:id/merge_requests, GET /projects/:id/merge_requests/:iid	getMergeRequests, rebaseMergeRequest
Preview/build statuses	GET /projects/:id/repository/commits/:sha/statuses	getMergeRequestStatues

In particular, entriesByFolder still calls REST listFiles, readFile, and readFileMetadata. allEntriesByFolder selects the batched GraphQL reader, but its cache-validation callbacks still include REST branch, compare, refs, and file-ID requests. File collections and single-entry reads also retain REST.

Remaining writes

• POST /projects/:id/repository/commits: create/update/delete files, including new editorial branches.
• POST /projects/:id/merge_requests: create an editorial merge request.
• PUT /projects/:id/merge_requests/:iid: update labels or close it.
• PUT /projects/:id/merge_requests/:iid/rebase: rebase it.
• PUT /projects/:id/merge_requests/:iid/merge: publish it.
• DELETE /projects/:id/repository/branches/:branch: delete the editorial branch.

These are an inventory of remaining REST calls, not a claim that every endpoint has a compatible GraphQL replacement. Raw/LFS downloads and mutations need a GitLab API/version check before deciding to port them.

Suggested first step

Start with paginated collection browsing and the remaining per-file content/metadata reads. Compare request counts and load times with REST on the same collection, then handle editorial workflow operations separately. Keep cursor behavior, permissions, cache invalidation, binary/LFS content, and self-hosted GitLab compatibility covered. GraphQL complexity limits already have a separate report in #7627, and token refresh is covered by #7931/#7932.

Source: API implementation and backend callers.

@martinjagodic, does the collection-browsing path look like the right first piece?