Pagination, Filtering and Sorting — Node.js & Express Backend

Every API that returns collections faces the same challenge: the data set grows over time, but clients have limited memory, bandwidth, and time. An endpoint that returns all 50,000 player records in a single response is not a functional API for any real application. Pagination, filtering, and sorting are the three mechanisms that give clients control over which subset of a collection they receive and in what order. Getting these mechanisms right has implications beyond convenience: the pagination strategy you choose affects your database query complexity, the consistency of results across pages, the cacheability of responses, and the complexity of the client-side implementation. This lesson covers the three primary pagination strategies and the standard conventions for filtering and sorting query parameters, with the trade-offs of each approach explained clearly enough that you can make the right choice for a given use case rather than defaulting to whatever example you last saw.

Analogy🏏Cricket

🏏 Think of it like cricket: In a Test match, there are multiple types of scheduled breaks and interruptions, each with different priority levels and timing rules. The lunch break (setTimeout) is scheduled for a specific time but can be delayed if a wicket falls just before — it fires at the next available opportunity after its scheduled time, not at the exact scheduled time. The drinks break (setImmediate) is taken at the end of the current over, as soon as the ongoing delivery sequence finishes. The umpire's over-rate check (process.nextTick) happens immediately after each delivery, before the next batsman faces — it cannot be deferred. The DRS review resolution (Promise microtask) happens between deliveries, after the umpire check but before any scheduled breaks. Just as the match referee would be furious if an umpire kept conducting over-rate checks after every single ball indefinitely (starving nextTick), the event loop is unable to proceed if process.nextTick callbacks keep registering new nextTick callbacks recursively. The insight is that each timer primitive is not just a delay mechanism — it is a specific position in a formal protocol, and misusing it violates that protocol's invariants.