If you've ever built an app that shows a list of things—whether it's blog posts, products, or users—you've likely hit a wall: as your list grows, your app gets slower. Eventually, it might even crash.
The solution to this problem is Pagination. To truly master it, we need to look at it through three lenses: Why we need it, What it actually is, and How we implement it.
You can also read other blogs on my website
1. WHY: The Problem of "Too Much Data"
Before we learn how to build pagination, we have to understand the disaster that happens without it. Imagine you have a database with 100,000 users. If you try to fetch all of them at once:
- The Server Chokes: Your database has to read 100,000 rows from the disk, package them into a massive JSON file, and send it over the internet. This takes a lot of time and CPU power.
- The Internet Connection Struggles: Sending a 50MB file to a user on a mobile phone will take forever. The user will see a loading spinner (or a blank screen) and likely leave your site.
- The Browser Crashes: Once the phone finally receives that 50MB file, it has to turn that data into 100,000 rows of HTML. Most mobile browsers will run out of memory and simply crash the tab.
In short: We use pagination for speed, stability, and to save on server costs.
2. WHAT: The Definition of Pagination
Pagination is the process of dividing a large dataset into smaller, manageable chunks (pages) and providing a way for the user to navigate through them.
Instead of asking for "all users," you ask for "the first 20 users." When the user is ready for more, you fetch the "next 20 users."
Think of it like a book. If a book was just one long, continuous scroll of paper, it would be impossible to handle. By breaking it into pages, the author makes the content "consumable." You can read a little, stop, and come back later to exactly where you were.
3. HOW: The Three Main Strategies
There isn't just one way to "paginate." Depending on your app's needs, you will choose one of these three implementation methods.
Method A: Offset Pagination (The \"Page Number\" Approach)
This is the most common \"How.\" You tell the database to skip a certain number of items and then take a specific amount.
- The Logic: \"Skip 40 items, and give me the next 20.\" (This would be Page 3).
- Best For: Simple apps where you need to jump to a specific page (e.g., \"Go to Page 10\").
The Code (SQL):
-- Fetch 20 items for Page 3
SELECT * FROM products
ORDER BY created_at DESC
LIMIT 20 OFFSET 40;
Method B: Cursor Pagination (The \"Bookmark\" Approach)
Instead of counting how many items to skip, you use a specific item as a pointer.
- The Logic: \"Give me the next 20 items that come after the item with ID #505.\"
- Best For: Large, constantly changing datasets (like a Facebook or Twitter feed).
The Code (SQL):
-- Fetch the next 20 items after a specific ID
SELECT * FROM products
WHERE id < 505
ORDER BY id DESC
LIMIT 20;
Method C: Infinite Scroll (The \"Automatic\" Approach)
This is actually a frontend \"How\" that usually uses Cursor Pagination in the background.
- The Logic: As the user's screen reaches the bottom of the list, the app automatically triggers a request for the \"next page.\"
The Code (JavaScript):
// Simple logic to fetch more data when scrolling
window.onscroll = function() {
if (window.innerHeight + window.scrollY >= document.body.offsetHeight) {
// We hit the bottom!
// Use the last item's ID as our 'cursor'
const lastId = document.querySelector('.item:last-child').dataset.id;
fetchMoreData(lastId);
}
};
Summary Comparison
| Why use it? | What is it? | How is it built? | |
|---|---|---|---|
| Offset | Simplicity | Page Numbers |
LIMIT and OFFSET
|
| Cursor | Performance | Bookmarks | WHERE id > last_seen_id |
| Infinite Scroll | Engagement | Continuous Feed | Auto-fetching more data |
Top comments (0)