Filters logic should be on frontend or backend?

user_5343376 0
Viewed 31396

I’m creating a web application

Frontend - reactjs and backend java.

Frontend and backend communicate with each other via rest.

On UI I show a list of items. And I need to filter them for some params.

Option 1: filter logic is on front end

In this case I just need to make a get call to backend and get all items. After user choose some filter option filtering is happening on ui.

Pros: for that I don’t need to send data to back end and wait for response. Speed of refreshing the list should be faster.

Cons: If I will need multiple frontend clients. Let’s say a mobile app. Than I need to create filters again on this app too.

Option 2: filter logic is on back end

In this case I get all list items when app is loading. After user changes the filter options I need to send a get request with filters params and wait for response. After that update a list of items on UI.

Pros: filter logic is written only once.

Cons: Speed probably will be much slower. Because it takes time to send request and get a result back.

Question: Where the filter logic should be? In frontend or in backend? Or maybe what is a best practice?

reactjs rest java
4 Answers

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.

user_73765260

This depends on the size of your data. For eg: If you are having a large amount of data, it is better to implement the filter logic on the backend and let the db perform the operations.

In case, you have less amount of data, you can do the filter logic on the front end after getting the data.

Let us understand this by an example. Suppose you have an entity having 1,00,000 records and you want to show it in a grid. In this case it is better to get 10 records on every call and show it in a grid. If you want to perform any filter operation on this, it is better to make a query for the db on the backend and get the results

In case it you have just 1000 records in your entity, it will be beneficial to get all the data and do all the filter operations on the frontend.

user_70759300

Most likely begin with the frontend (unless you're dealing with huge amounts of data):

  1. Implement filtering on the frontend (unless for some reason it's easier to do it on the backend, which I find unlikely).
  2. Iterate until filtering functionality is somewhat stable.
  3. Analyze your traffic, see if it makes sense to put the effort into implementing backend filtering. See what percentage of requests are actually filtered, and what savings you'd be getting from backend filtering.
  4. Implement (or not) backend filtering depending on the results of #3.

As a personal note, the accepted answer is terrible advice:

  • "If you had a million records, and a hundred thousand users trying to access those records at the same time"; nothing is forcing the hundred thousand users to use filtering, your system should be able to handle that doomsday scenario. Backend filtering should be just an optimization, not a solution.
  • once you do filtering on the backend you'll probably want to do pagination as well; this is not a trivial feature if you want consistent results.
  • doing backend filtering is likely to become much more complex than just frontend filtering; you should be aware that you're going to spend a significant amount of time (not only for the initial implementation but also for ongoing maintenance) and ask yourself if it's not premature optimization.

TL/DR: Do wherever is easier for you and don't worry about it until it makes sense to start optimizing.

user_17807260

It depends on the specific requirements of your application, but in my opinion the safer bet would be the back-end.

Considering you need filtering in the first place, I assume you have enough data so that paging through it is required. In this case, you need to have the filtering on the back-end.

Lets say you have a page size of 20. After you apply the filter you would expect to have a page of 20 entities that match that specific filtering criteria in the UI. This can't be achieved if you fetch 20 entities, store them in the front-end and afterwards apply the filter on them.

Also, if you have enough data, fetching all of it in the front-end will be impossible due to memory constraints.

Admin1
Related