Pagination: Server Side or Client Side?
Numerous times in your projects you might have to face a situation where you need to pull chunks of data dynamically. The obvious issue that you then face is pagination\sorting and filtering. You then start to think if it would be better to handle it all at the server side or should hold back and handle it on the client side.
Well there is no clear winner amongst the two; neither there is a right or wrong approach.
The right answer depends on your priorities and the size of the data set to be paginated.
If you have large number of pages doing it on client side will make your user download all the data at first which might not be needed, and will defeat the primary benefit of pagination. In such a scenario you are better of requesting pages in chunks from the server via AJAX. So let the server do the pagination. You can also pre-fetch the next few pages the user will likely view to make the interface seem more responsive. However, when implementing it, you need to make sure that you’re optimizing your SQL properly. For instance, I believe in MySQL, if you use the LIMIT option it doesn’t use the index so you need to rewrite your SQL to use the index properly.
If there are only few pages, grabbing it all up-front and paginating on the client may be a better choice. That gives you the obvious benefit of faster subsequent page loads. Unless really required we should not choose the Server side pagination in such a case.
Server side pagination is better for:
- Large data set
- Faster initial page load
- Accessibility for those not running JavaScript
- Complex view business logic
- Resilience to concurrent changes
Client side pagination is better for:
- Small data set
- Faster subsequent page loads
- Sort & filter requirements supported fully (unless results greater than max size).
To sum up, if you’re paginating for primarily cosmetic reasons, it makes more sense to handle it client side. And if you’re paginating to reduce initial load time, server side is the obvious choice. Of course, client side’s advantage on subsequent page load times diminishes if you utilize Ajax to load subsequent pages.
for more information click here
Comments\suggestions are welcome.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)










Comments
Daniele Gariboldi replied on Tue, 2009/01/27 - 4:48am
I think the best is to do both: server side paging and prepare next and previous pages ready for the client. If you prepare a component to do this, it's easier to use it both for small and for big dataset.
Data could be small at start, but you don't know and could grow.
I use hibernate and it is good for pagination (using a cursor). I usually do ACL rights check in SQL too, to avoid fetching rows I then have do discard because the user as no right to see them.
yuvika replied on Tue, 2009/01/27 - 10:09am
nitinaggarwalin replied on Tue, 2009/01/27 - 10:15am
in response to: garidan
very well pointed out Daniele,
Like I said There is no right or wrong in it, that is another very nice way to do it.
Ashish replied on Tue, 2009/01/27 - 11:28am
What about server side but using AJAX calls?
It will experience of client side pagination but robustness of server side.
you can pre-fetch prev & next pages (Hint google map)
aarkay007 replied on Tue, 2009/01/27 - 12:07pm
Setya replied on Tue, 2009/01/27 - 1:43pm
Hi,
Not all database provides syntax to perform paginated query.
SQL Server has TOP, but it only queries the first N rows not a subset of rows. Oracle provides ROWNUM, but last time I check it also returns first N although it supports ROWNUM BETWEEN N AND N.
In this situation you have no choice but using :
1. Subqueries, which is cumbersome for complex queries.
2. Hibernate, which provides pagination exposed via its Criteria & Query API.
Regards,
Setya
lucek replied on Wed, 2009/01/28 - 7:19pm
nitinaggarwalin replied on Fri, 2009/02/06 - 8:53pm
in response to: ajainy
Hi Ashish I agree to your solution and I have already hinted on that approach.
nitinaggarwalin replied on Fri, 2009/02/06 - 8:54pm
in response to: lucek
nitinaggarwalin replied on Fri, 2009/02/06 - 8:58pm
in response to: aarkay007
Hi this is absolutely a relative descision aarkay. One need to take a call on that. Typically if your resultset returns you hundreds or pages you would consider that a large dataset while if it is just a few pages i would reckon that as a smaller dataset.
Normally we dont consider the number of columns but in extreme cases we may need to.
The primary concern remains the number of rows we fetch in the overall resultset.
Michal Rembiszewski replied on Sun, 2009/02/08 - 5:29pm
urban_skinny replied on Sat, 2009/03/07 - 12:46pm
sunrise1 replied on Fri, 2009/10/23 - 3:02am
sunrise1 replied on Sun, 2009/10/25 - 9:50am