Filters logic should be on frontend or backend?

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.

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.

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.