Is it advisable to perform additional logic on data in the front-end?

When receiving data to display in the front end is it advisable to perform additional logic on that data in the front-end - e.g. checking columns if they contain specific values, then hiding the columns, or should this be done in the backend which should return to front-end just a boolean value?

My worry is that when the data grows it will drastically affect performance of the app in the browser. If yes what arguments should be used in discussion with people who do not agree / don't want to find time to do it?

I'm, using Angular ngFor to display data, but obviously I need to perform that logic before building the DOM.

2 Answers
2

Yes, It's advisable to do that.But there are few cases to consider:

Scenario 1: There are ~million customers and each customer holds data of ~1000 rows.
In this scenario, its better we do most of our filtering on client side, hence reducing the load on server and it can serve more requests.

Scenario 2: Any number of customers and each customer holds data of ~10000 or ~million rows. In this scenario, we have to go for server side pagination as we should not transfer whole data. Each filter applied on the client side will potentially trigger a server call to fetch the data.

In general, the client side filtering should not impact app performance as laptop/PCs/frameworks now a days can easily handle the load. But, we should not consider sending data of ~million rows and try to perform actions on client side. It will impact both client and server performance.

Thanks for your answer
– Always_hungry
2 days ago

There are a couple of different approaches to this. The first thing I always recommend is to treat your backend like some sort of public API which does not know anything about your frontend view. This kind of answers it already for a lot of use cases. If your API is build properly (and does not do weird/mixed/inconsistent returns) returning "everything" is usually fine.

The second thing you need to keep in mind is the amount of data you are talking. Well if it is a data set with 1000 array entries for objects with 20 properties, just don't worry - Angular (and JS) is pretty darn fast and you wont even notice the difference between array with 10 entries or 1.000 or 10.000 (request size could play a factor tho. But for regular text returns we are still talking just kB and with todays internet speed thats not a problem).

The next thing important is there is a difference between handling large arrays/objects in JS and in the DOM. Having a regular ngFor and displaying 10.000 entries at once will definitely slow down/lag your browser. But for this case you can use some sort of virtual-repeat, were only 10-50 entries (that are currently visible in the DOM) are rendered, and when you scroll they are just reused instead of creating new ones.

The last point is to try to write performant checks. You said you want to hide/show columns based on the result. Well if it just needs to be evaluated once try to put it in a variable/"one-time-binding" instead of checking the same condition each digest cycle. If the check takes to long because it is quite complex, try to react on the event that may change the values instead of checking each digest cycle.

So what to take from this short write up:

Fantastic answer!
– Always_hungry
2 days ago

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.