Nitin has posted 4 posts at DZone. View Full User Profile

Pagination: Server Side or Client Side?

01.27.2009
| 26540 views |
  • submit to reddit

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.

Published at DZone with permission of its author, Nitin Aggarwal.

(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 - 3: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 aggarwal replied on Tue, 2009/01/27 - 9:09am

Its a nice article and I agree with the comment.

Nitin Aggarwal replied on Tue, 2009/01/27 - 9:15am in response to: Daniele Gariboldi

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 Jain replied on Tue, 2009/01/27 - 10: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)

 

 

Ram Kompella replied on Tue, 2009/01/27 - 11:07am

how do you decide whether its a large or small dataset? and do you consider no. of columns?

Setya Djajadinata replied on Tue, 2009/01/27 - 12: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

 

Maciej Klepaczewski replied on Wed, 2009/01/28 - 6:19pm

MySQL uses index with LIMIT option. Why wouldn't it?

Nitin Aggarwal replied on Fri, 2009/02/06 - 7:53pm in response to: Ashish Jain

Hi Ashish I agree to your solution and I have already hinted on that approach.

 

Nitin Aggarwal replied on Fri, 2009/02/06 - 7:54pm in response to: Maciej Klepaczewski

Well I am not a MySQL expert probably need to refer MSDN for that :P

Nitin Aggarwal replied on Fri, 2009/02/06 - 7:58pm in response to: Ram Kompella

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 - 4:29pm

Caching on the server forces you to have a stateful session which has many drawbacks and I wouldn't go for it just for the sake of paging. If you have it already, caching there is probably the easiest approach. If you don't want a server state, I'd go with a client cache fetching say 3 first pages because average user seldom goes past that. When he does, grab next 3 and so on. You obviously loose the "go to the end" button, but I doubt it's critical in most scenarios.

James Bertrude replied on Sat, 2009/03/07 - 11:46am

I was considering client side pagination for a current project, however, as search engines then only crawl the one page, the users dont get directed from the searches to the right 'page' number?? or am i missing somehting?

john green green replied on Fri, 2009/10/23 - 2:02am

Caching on the server forces you to have a stateful session which has many drawbacks and I wouldn't go for it just for the sake of paging. If you have it already, caching there is probably the easiest approach. nike shoes newIf you don't want a server state

john green green replied on Sun, 2009/10/25 - 8:50am

SQL Server has TOP, but it only queries the first N nike shoes china 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.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.