Sanity Content Lake API and Frontend Pagination: Total Count Retrieval

Answer

Yes. GROQ can return both a filtered total count and a paginated slice in a single request by wrapping them in an object projection. The limitation described only applies to a bare slice query such as *[filter][$start...$end], which returns an array with no metadata. A wrapper object solves this directly.

Single-Query Pattern

Use the same predicate for both the count and the page slice, and sort deterministically before slicing:

{
  "total": count(*[_type == "post" && ]),
  "items": *[_type == "post" && ] | order(_updatedAt desc, _id asc)[$start...$end]{title, slug}
}

This returns one payload containing both values. The client receives a consistent snapshot from a single query execution, eliminating the need for a second count request.

Constraints and Trade-offs

• Deterministic sorting: Always include a unique tiebreaker such as _id asc after _updatedAt desc. Without it, documents created, updated, or deleted between page requests can cause duplicates or gaps.
• CDN consistency: The CDN endpoint serves cached, eventually consistent responses. If the wrapper query is cached, total and items come from the same cached snapshot, which is usually safer than combining separate cached requests. If read-after-write consistency matters more than cache performance, use the API endpoint instead.
• Payload size: count() itself is lightweight, but the filter still evaluates matching documents. Keep the page projection minimal—return only the fields the list UI needs.

Verification

Before relying on this pattern, test with a filter that matches a known number of documents. Assert that total equals that number and that items has the expected page length. Request an offset beyond total and confirm items is empty while total remains unchanged. If you use the CDN, compare responses immediately after a create or delete to observe any count lag.

One diagnostic detail would change the endpoint recommendation: if your pagination must reflect writes immediately after a create or delete, use the API endpoint instead of the CDN. Do you need read-after-write consistency, or is eventual consistency acceptable for your UI?