I remembered in my previous job, I was a frontend Dev and there is a backend developer. There's a task where computations are needed before presenting data in the frontend. Backend Dev asked me to do the computations in the frontend instead. Well well 🤷‍♂️

Have you experienced this before?

You can't generalise. If it's something simple (that won't slow down a phone for example), why not?

@kamen Never put business logic in frontend.

You can control backend, but you can't never control frontend

You can only move things like filtering, pagination and sorting to the front-end if you can pass the whole dataset.

If it's a small dataset... and it's never going to get bigger... IDK, sometimes it is easier to just pull the whole thing and do the fancy shit on the front end.

But ONLY for small datasets.

@pmso never say never.

Computation is highly unspecific.

If it's sth. like X = Y+ Z where Z and Y already exist... It makes no sense to redo an existing API.

If it's something complex - e.g. currency conversion - it should be done via an API.

Aggregation would be another good case for things that should be done in an API.

Based on complexity, it might or might not make sense to move sth to an API.

Even in the client side one should write proper modularized / maintainable code... And not one spaghetti file ;)

@HiFiWiFiSciFi this seems like a great idea to run into trouble when your dataset changes

Can't generalize indeed.

I'm currently calculating the correct properties to feed a CSS transform with based on container size and mouse position data. That calculation doesn't modify the dataset, the dataset modifies the initial variables (container size) I am working with.

It would make no sense to do that in the backend at all.