I’m creating a web application.
The frontend uses ReactJS, the backend uses Java.
They communicate with each other via REST.
On the UI, I show a list of items. And I need to filter it by some params.
Option 1: the filter logic is in the frontend
In this case, I just need to make a get request to the backend and get all the items. After a user chooses a filter option, filtering is happening on the UI.
Pros: For that, I don’t need to send data to the backend and wait for a response. Speed of refreshing the list should be faster.
Cons: If I need multiple frontend clients, let’s say a mobile app, then I will need to create filters again in this app too.
Option 2: the filter logic is in the backend
In this case, I get all the list items when the app is loading. After a user changes filter options, I need to send a get request with filter params and wait for a response. After that, the list of items on the UI updates.
Pros: The filter logic is written only once.
Cons: The speed will probably be much slower. Because it takes time to send a request and return the result.
Question: Where the filter logic should be? In the frontend or in the backend? What is the best practice?
Filter and limit on the back end. If you had a million records, and a hundred thousand users trying to access those records at the same time, would you really want to send a million records to EVERY user? It'd kill your server and user experience (waiting for a million records to propagate from the back end for every user AND then propagate on the front end would take ages when compared to just getting 20-100 records and then clicking a (pagination) button to retrieve the next 20-100). On top of that, then to filter a million records on the front-end would, again, take a very long time and ultimately not be very practical.
From a real world stand point, most websites have some sort of record limit: Ebay = 50-200 records, Amazon = ~20, Target = ~20... etc. This ensures quick server responses and a smooth user experience for every user.