15

I've been having a discussion recently in the office, about whether to provide graph data prepared via our internal back-end api or to provided generic data and parse to graph format in the front-end. Here is the basic notes i've collected from my team:

Front End Pros:

  • Data is transmitted from the backend in a generic format
  • Because the data is in a generic form, any graph rendering front-end could be used. Provided a parser method is written

Front End Cons:

  • Front-end will need to included a parser of some sort, to convert the generic data into actual graph data

Back End Pros:

  • Data can be provided in the correct format negating the need for front-end parsing

Back End Cons

  • Locks down which graph library we can use

It seems as though its an either/or scenario, but i wanted to ask the question to gain any other possible insights.

By back-end i mean REST API and by front-end i mean web-application (Javascript).

Improve this question
3
  • 1
    I think you already wrote the answer yourself, you have more front-end pros .. Commented Aug 12, 2014 at 19:09
  • @ion And at the same time, all pros are not equal Commented Jan 4, 2022 at 0:53
  • REST API should not prepare a view, should only provide data, frontend is how you present it, plus the processing power is on the client-side, and plus the design can go wild. Commented Jan 5, 2022 at 8:35

3 Answers 3

Reset to default
11

To add more to your list you could take the following into account.

  • Serializing and manipulating data in the back-end uses more RAM, since all your data is first loaded into memory.
  • To keep your back-end standardized and structured, you should only be accessing resources through your REST API. Manipulating data on such a huge scale has no real value for your API.
  • Using front-end to manipulate the data will use more native resources, and therefore save your server heaps of processing and ram on creating the "graph" data. The graph will render at native speed, and not hang on the server to first construct it.
  • Unless you're writing applications that are constantly under threat of being hijacked/hacked (Like a bank). You don't really need to worry about someone else writing their own versions of your graphs. It takes too much time, and isn't exactly something you would need to consider a viable threat to the business/application.

Hope I helped a bit.
PS

I'd recommend using the back-end REST API as only a Database / resource exposure, and not have much application logic.

Your JS app should be handling all the data manipulation to structure whichever information it's trying to convey.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

I am currently utilising the same method. However, I am worried about a situation where the server has to send Lakhs of generic data rows. In that case its too much of information is to be sent to the frontend. Meaning more data for the client to download. Instead if we process the data in the backend it would only send a few bytes compared to sending Lakhs of rows to the frontend. I sometimes wonder if the decision I took to send generic data to the frontend is the right one.
Sending loads of data in one request seems to be an infrastructural problem not a logical problem. Processing high amounts of data on your server is only required if you're aggregating something that you only request maybe a couple of times a day, for something more frequent, you don't want to lock processes up in aggregation when they should be dealing with requests. If you're sending really large amounts of data to your front-end, consider streaming it as opposed to aggregating it. @ShyamalParikh
6
  • expensive computations or any sort of computations for graph should happen on the back-end. Even if the back-end ends up consuming more memory or cpu, you can control that by scaling/autoscaling your back-end servers based on CPU, Response time , Memory, etc..
  • If front-end does the computations and lets assume it has years and months of data points, processing happens on the client's browser app for which your app has no control too. This is especially the scenario for those who play multiple browser tabs or apps at the same time.
  • Debugging or pin pointing the issue is easier if all computations are done on the back-end.
Improve this answer

Comments

1

If the back end is capable of doing the conversion, then ideally the client could have the option of getting raw or formatted output. Best of both worlds?

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.