I'm new here, so please be gentle.

I've been having issues at my workplace about the front-end team demanding me as a backend to provide every piece of data that has to be displayed in the front end. I just recently get into this job after graduating college, so it kinda baffles me, because I never process every bit of data in the backend REST-API to use ready for charts or other little things (like the sum or average of data).

My question is, Whose job actually is to process data in the database to become something like a chart in frontend? Is it backend, frontend, or someone else? or I totally mistook job desc for backend in general?

best regards.

2 Answers 2


There is no clear cut answer here that applies to everyone. Your question is too vague. But as you are new to this, a thought experiment:

You want to display the average user age. You have one million users.

  • If you don't do the calculations in the backend, you have to send one million integers (ages) to the frontend
  • If you do the calculations in the backend, you have to send one integer (the average age) to the frontend

From a purely bandwidth perspective, sending one integer is better than sending a million.

There are many more considerations here that are very contextual (e.g. what kind of reporting, whether you want to offload calculation complexity to the user device, available bandwidth, frequency of report generation, ...), all of which can change the decision that makes the most sense for that particular scenario.

Generally speaking, reporting tends to fall into both the "crunch once, read many" and "big data set" categories, which makes it a strong contender for backend-driven calculations.

  • Thanks, now it makes sense now. I think I got too stuck up to the standard for REST-API. I should probably make another API section for some specific actions to simplify the data process, not try to force it into the REST-API standard and end up falling. Thanks for your answer.
    – Alif Irhas
    Commented Nov 8, 2022 at 6:02
  • 3
    @AlifIrhas It's actually fairly common to have a RESTful interface for reports, specifically when they take the backend a nontrivial amount of time to compute. You could for example do a POST that requests a report and returns an ID for it, and a GET for that ID returns a HTTP 409 response while it's processing, and 200 with the content once it's complete. Commented Nov 8, 2022 at 9:51

I essentially agree with Flater's answer, but I'd just like to talk more about the principles.

The issue is really how to achieve an efficient division of labour, between the backend and frontend developers, and also between the backend and frontend machines.

Any business nowadays has a division between backend and frontend machines - the days of standalone workstations are long gone. They may or may not have a division between backend and frontend developers.

Machine workload

Firstly, on machine workload, if the volume of input data is large, and the volume of output small, then you normally want to do the processing as close to the source as possible (i.e. in the backend).

You might also want to do processing in the backend, if the backend machine simply has better facilities for processing than the frontend (for example, if the frontend has limited storage and processing capability).

However, if considerable processing horsepower is necessary to boil the data down, then eventually it may become a better configuration to transfer a large amount of raw data (or only part-processed data) to the frontend, and put some of the processing burden on a frontend machine which is capable of it, rather than to try and do it all in the backend.

If there is no significant processing, and if there is no significant reduction in volume between source and output, then which machine does the little processing work probably doesn't matter.

Developer workload

Secondly, on developer workload, if the processing itself is all simple and straightforward in nature, then which developers do it (backend or frontend) probably doesn't matter. Consistency of practice (and aligning with a good division of machine workload above) is probably the only consideration.

However, if there is enough overall work to justify a division into frontend and backend developers in the first place (rather than all being done by one person), then there may be a need to distribute development work to ensure each has a reasonable workload, and that neither is unreasonably bored or idle.

Another issue is conceptual complexity (i.e. the kind of problem that causes staff to struggle to understand things, even if the execution is not straining the machinery, and which bogs staff down in pure thinking time, mental exhausion, and stress).

Generally speaking, a backend developer will be responsible for constant oversight of an entire database (or estate of databases), whereas a frontend developer may be responsible for the finer details of a particular user requirement or functional area, and there is often better possibility for fan-out at the frontend.

When complexity becomes a problem in the pipeline of getting data from backend to frontend, it's typically a problem first for the backend developer, in which case it may be necessary to start simplifying what the backend developer provides to the frontend developer, and let the frontend developer handle more of the details of final processing or presentation.

Of course, if both sides are struggling, then either they need to manage complexity better, control demand, or add more experienced personnel.

It's relatively unusual for things to move from front to back for staff workload reasons - usually movement in that direction is for machine workload reasons.


In many cases, there may be a conflicting configuration of these two concerns (for example, processing ideally being done on backend machines, but the backend developer being overworked), and it will be a question of trying to balance them both and achieve reasonable compromise, or evaluating the relative cost of adding more resources of each kind (man and machine).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.