We all know that nothing makes us leave and abandon a site,
than a site having a slow load time…
To the simple site user, consumer.. api and api loading data is not their concern or even something they are aware of.. but as developers we must take into consideration all possible issues that may involve a user’s experience..
One of the many ways, this can be accomplished… is by “optimizing api’s for peak efficiency”…. and this can be done with api pagination!
So what is pagination?
Have you ever been on commerce store and went through many products, and was able to flip through the products pages and view a certain amount of them per page…
or scrolled through a gallery of images, only to be click next so that you may browse through another section.
this is essentially pagination!
Let's have a look at the most common pagination methods today!
it uses filtered values of a pages to determine the next group of items…
- Client wants to see the most recent 20 products GET /items?limit=20
- Upon clicking next, the query finds the minimum created date of 2019–01–20T00:00:00. That’s then used to create a “query filter” for the next page. GET /items?limit=20&created:lte:2020-01-20
The benefit to this approach, is this can be done without requiring more backend logic, other than that initial URL parameter!
this is done using two main commands: “Limit” & ”Offset”, these are mostly popular with apps that hooked with SQL databases
the benefit to this approach is, it requires almost no programming, its stateless server-side wise but it also comes with the cons of offsetting large values, because the api would be forced to scan through a 100,000 database entries before discarding them.
this is done using the queries..”after_id” & “before_id”, because unique ID’s are more reliable than field names such as Category name or product name..
Consider this example:
- Client requests a list of the most recent items GET items?limit=20
- Client requests a list of the next 20 items, using the results of the first query GET /items?limit=20&after_id=20
- Client requests the next/scroll page, using the final entry from the second page as the starting point GET /items?limit=20&after_id=40
think of seek pagination as searching through a database using “WHERE”
in the case where you are sorting items by id:
And what if you were searching by usernames:
this would require two rounds of queries in the backend:
the first would search the database for those usernames and then translate them into an ID
and then a second query would use the id’s as “Where” value..
the benefits of this method: it works really well and efficiently with large offsets.
it consistently orders items and sorts the newly added ones as well.
the biggest con is when there’s items deleted from the database … “start_id” may no longer be valid.
I hope this was a nice intro to pagination, please make sure you continue to learn and try new logic with every new project :) Happy Coding!