Pagination
🏠The everyday picture
A phone book is split into pages. Nobody photocopies the whole book to find one number.
📘What it really is
- List endpoints must never return everything at once: lists grow, responses get slow, and memory runs out.
-
Offset pagination:
GET /enquiries?page=3&pageSize=25(orlimitandoffset). Simple, and lets people jump to any page. It gets slow on very large tables, and items can shift between pages if new ones are added while someone is paging. -
Cursor pagination: the response includes a
nextCursor(often the id or time of the last item);GET /enquiries?cursor=abc&limit=25continues from there. Stable and fast for large or fast-changing lists; ideal for "load more" and infinite scroll; can't jump to page 50. -
Return paging information with the data:
{
"data": [ ... ],
"page": 3,
"pageSize": 25,
"total": 412
}
- Set a default page size and a maximum (for example 25 and 100), so clients can't request a million rows.
- Validate paging parameters with your schemas (Module 43): numbers, within limits.
🖱️Try it
Add offset pagination to GET /enquiries, with a default of 25, maximum 100, and total in the response. Validate the
parameters. Connect the React table's pagination from Module 40 to it.
✅Quick check
Why set a maximum page size?
Show the answer
So nobody can request huge pages that overload the server or database.
An inbox shows newest first and new enquiries arrive constantly. Offset or cursor pagination?
Show the answer
Cursor pagination, which stays stable while new items are added.