Frontend vs Backend Filter

Any web application will encounter the situation where you have to show a little bit too much data to the user. Processing a lot of information will cause your application to slow down notably and humans are not able to comprehend a lot of information in one look. Having a way to easily find the information you are looking for becomes necessary.

A common technique to organize and limit data is using pagination. The idea here is to only show a limited amount of data at the same time, and as the user goes to the next page we load new data and show him. While pagination helps with avoiding too much data to process and thus slow down your application, it doesn't help the user in finding what he is looking for. For that we need an actual filter. A filter can be as simple as a freeform text input or a set of specific fields to filter per attribute.

Both the pagination and the filtering can be done on either front-end or back-end, with each their own advantages and disadvantages. Let's first look at doing it at the front-end.

The big disadvantage of doing pagination and filtering on the front-end is that the back-end still has to send all data to the front-end which can cause slow requests, moreover the front-end will have to process all the data as well before it can show any data. The big advantage of doing it at the front-end is that you can keep your API very simple. You don't have to pass the filter and pagination parameters to your API. The very slow initial load also means you don't need any other requests after that. Not matter what the user does on the page, you already have all the data. Processing the data when the filter changes can also be challenging as you will always have to process all elements.

Doing all this at the back-end has the complete opposite advantages and disadvantages. The response will be smaller and the front-end only has to deal with a small amount of data. However, upon every change to the filter or page, you need to send a new request to the back-end and fetch new data. This can cause small delays whenever the user makes a change. Moreover you have to adjust your API such that all information can be send. For the best performance and results, you should do filtering and pagination on the database query directly. This means that all the parameters have to passed down to the deepest level.

Filtering data can either be done on the front-end or the back-end and most people will opt to go for the back-end approach as this improves performance a lot. You are able to filter at the source (in the database even), which results in less data to be sent to the front-end, meaning your application will load faster. The big downside however is that your API can quickly become very complicated.

I tend to be in favour of the back-end solution, but this does not mean that I always implement a full pagination and filtering mechanism on every API. On the contrary, I typically start of with a very simple API that returns everything. As long as the data size remains manageable there isn't a need for it. A quick next step could be to add filtering on the front-end when users can't find the information they need. In the end, I would extend the API to do the filtering on the back-end, but that is a long term solution and would require a bigger investment. In some cases you can already predict that this will happen and it will be worthwhile to design the API with pagination and filtering from the start.