when to implement server side pagination
I have implemented a search and pagination in React. The search is basically using .filter. The data is coming from MongoDB/Node.js but there is no pagination on the backend.
The reason I like doing it purely on the frontend is because it is really fast but it wouldn't be good to load 1000's of records at once from the api I would imagine and sending only say 10 records at a time from the backend would be better. But then I would lose the speed and couldn't use filter on the search anymore for all records because I have limited data and I would need to send the search query to the server. (I assume!)
So, my question is if I am anticipating about 30 records per month per user to be added then after 12 months, a user would be loading 360 records at once which they could then 'search' and go through the pagination all on the client side.
What is the rough number of records where this would become problematic and implementing pagination on the backend would be necessary? I am trying to determine if I can leave it as is or need to sort of future proof the application by implementing server side pagination.
The reason I like doing it purely on the frontend is because it is really fast but it wouldn't be good to load 1000's of records at once from the api I would imagine and sending only say 10 records at a time from the backend would be better. But then I would lose the speed and couldn't use filter on the search anymore for all records because I have limited data and I would need to send the search query to the server. (I assume!)
So, my question is if I am anticipating about 30 records per month per user to be added then after 12 months, a user would be loading 360 records at once which they could then 'search' and go through the pagination all on the client side.
What is the rough number of records where this would become problematic and implementing pagination on the backend would be necessary? I am trying to determine if I can leave it as is or need to sort of future proof the application by implementing server side pagination.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
1. Fields that the user fills values into before requesting the results from the server.
2. One man's meat ... personally I would keep it in the hundreds - but it depends entirely on the data set
2. One man's meat ... personally I would keep it in the hundreds - but it depends entirely on the data set
ASKER
1. Okay, so they basically choose the data they want upfront. Don't think that will work in my case as they basically go to a page which has a table and loads all their records with the pagination and search.
2. Sounds good. I did actually implement some server side pagination which works nicely but it totally messes up my filter/search because I was using SWR in my frontend end only pagination/search.
Anyway, I have a server side implementation for pagination in case I ever need to use it in future but based on what said about keeping it in the hundreds I think I will do everything client side for now.
Thanks for your answer!
2. Sounds good. I did actually implement some server side pagination which works nicely but it totally messes up my filter/search because I was using SWR in my frontend end only pagination/search.
Anyway, I have a server side implementation for pagination in case I ever need to use it in future but based on what said about keeping it in the hundreds I think I will do everything client side for now.
Thanks for your answer!
You are welcome.
ASKER
2 questions.
1. What do you mean by have a query form?
2. What would you consider a dataset that is too large to load client side ie: how many records. In my case the records just consist of basically some text data like title, date, id and price.