Web applications, like books, have to be written with their true audience in mind. Like the choice of words an author has for a masterfully crafted story, a developer must choose the correct solution to every problem. One problem almost all applications face is having to display large amounts of data in an organized manner to its users. This can be an administrative portal that is displaying all employees, an educational tool displaying all courses, or even a shop displaying its transaction history and status. The possibilities are endless and to some developers, the solutions may be as well.
The quantity of the data plays a big role in deciding how a data-heavy page is going to be loaded. Are there 20 rows of data? Are there 2,000 rows of data? Are there 2,000,000 rows of data? Pagination is the process of batching data so that only a subset of data is viewed on a page at one time. We have all seen our favorite shopping site with a grouping of items that we have to click through to see the next page of products. This is an example of pagination, however there are multiple ways to handle the logic of pagination. Pagination can be handled either ‘Client Side’, or ‘Server Side’.
Server Side Pagination
Server Side Pagination is when the server in which the data is hosted only returns a subset of the data requested by the Client. For instance, in an application used for searching for apartments or homes on the market, we may apply our filters of 2 bedrooms, 2 bathrooms, and in-unit laundry and then we may search the system. Ten thousand results may match our search criteria, but the server only sends a portion of the results back to the Client (which in this case is our webpage). Along with the subset of the query results, the server also sends us the total amount of results matching our query, and the location we are at within the query. These three pieces of data tell us the main things needed for pagination. What results we wanted, how many results there are, and where in the list we are retrieving our results.
Getting only a portion of the results at a time gives us the ability to come back for more, loading additional items only when requested. Server Side Pagination is like ordering a meal at a restaurant. The restaurant only brings you what you ask for, but you have to wait for them to make it. Just like a restaurant during off hours, the food, or (data in this analogy) comes fairly quickly as only a couple items are being requested. However during times with peak activity, things may slow down as a bunch of requests come in all at once. Sometimes this means that a bigger kitchen (or more powerful server setup) may be required to handle all the requests.
Server Side Pagination is like ordering a meal at a restaurant. The restaurant only brings you what you ask for, but you have to wait for them to make it.
Client Site Pagination
Client Side Pagination means that when a query is made, the server returns to the client all the data in one big chunk. Client Side Pagination is more like going to a restaurant and ordering one of everything on the menu. The time it takes the kitchen to produce all that food is going to be significantly longer. However, once it is all at the table, it is super easy to switch from eating one thing to another. Because of the way the data is retrieved all at once, flipping through these items can be lightning fast as we never have to tell our waiter to bring us something new, we have it already.
Client Side Pagination is more like going to a restaurant and ordering one of everything on the menu. The time it takes the kitchen to produce all that food is going to be significantly longer. However, once it is all at the table, it is super easy to switch from eating one thing to another.
Choosing the Best Solution
To determine which style of pagination is best for your application, you have to look at three major components.
1. How complex is the data?
The more complex the data is or more connections it has to other tables in a database, the slower retrieving the data from the database will be.
2. How large is the dataset?
A larger dataset means more data is being sent to the client.
3. How is the main audience going to interact with the data? How often will they be searching and sorting?
For someone who is interacting with the data frequently, the more the Client has to request the data from the server.
For instances of high interaction, simple data or a low resulting query, I would recommend client side processing. The biggest downfall to Client Side Processing is that all the data gets loaded when the user first accesses the page with the table on it. Pulling a large dataset can mean waiting longer for the page to load. This load time can increase significantly as the data results grow and the data becomes more complex. I have seen load speeds of 40+ seconds in certain scenarios. The advantage of this solution is that any sorting, searching or filtering can be done incredibly quickly by the client because the web page itself can handle all of that functionality without going back to the server.
For instances of low interaction, complex data or a large resulting query, I would recommend server side processing. Server Side Processing is better suited to handle the more complex datasets because the server only gives the client the portion of data that it needs, which means the initial load will be lightning quick. However, the downfall of Server Side Processing is that the client needs to continue to request more data from the server every time the user interacts with it. With each interaction having to reload the data within the table, this can be tedious to the user experience if not handled with meaningful thought.
With all of this being said, if your use case and data is simple and easily managed, then I would go the ‘quick and easy’ route of Client Side Pagination. If the application has the potential to grow rapidly, I would take the time to build out the Server Side Pagination and processing so that you don’t have to suffer through a significantly increased load time. In the end, if your budget or timeline does not allow for the more lengthy build, start ‘quick and easy’ but do not be afraid to refactor or redevelop portions of your application that no longer fit your needs. An application is built to suit the needs of its users not the other way around. If you are feeling trapped by your own application, give us a call, we can help!