Support limits for offset pagination and define default

In &2039 we are working to move most heavier searches to a keyset pagination strategy, rather than offset based. This has significantly faster response times and performance on the database.

In order to drive usage of the new keyset based pagination, we will need to allow a limit to be set for offset based pagination, and we should define a default limit. The reason for a configurable limit is that some customers may have existing homegrown integrations which depend on offset based searches, and it may not be trivial to swap over to keyset. (Upstream library or service, keyset pagination does not support filtering, etc.)

Why a configurable limit

By specifying a healthy default we are encouraging good development practices across our user base, but by allowing it to be configurable we are recognizing that we:

• Currently lack the visibility to know how heavily offset based pagination is being used on self-managed instances
  • Adding this instrumentation, then waiting for uptake of the new version, will significantly delay the implementation of a limit
• Do not know all of the GitLab integrations out there and there could be large instances with a requirement for supporting offset based pagination for some time to come. (For example the APIv3 deprecation was significantly delayed to its usage in the Jenkins plugin.)

Configurable limits is also a model we are driving towards across the broader application: &1737

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.