38

I have a web application, and I'm wondering if its better to format the data in the front-end or the backend? They both get the job done, but can someone help me brainstorm which is the better option between the two.

As an example, say I have a backend that returns the a family tree of names in a certain format, but in the front-end I need to adjust the format to match the format a widget expects, should this adjustment be done in the backend or the front-end?

If its done in the backend, I can straighforwardly push the data into the widget in the front-end else, I would have to parse in the front-end beforehand. Can anyone think of pros/cons for this situation? Thanks.

dchhetri
  • 6,926
  • 4
  • 43
  • 56
  • In this kind of context there is always a trade-off in my experience of the followings: * can I touch the backend? (not always sure...) * does the new format process require a big effort? In general, depending of the current load of the backend, I prefer to distribute the effort in both back and front-end. Nowadays browser have decent performances and unless you have to order million rows it's acceptable. – MarcoL Nov 19 '13 at 17:06
  • 1
    Also, depending on your needs, you can cache your formatted data on server-side. – jtlowe Nov 19 '13 at 17:16
  • 1
    Personally I try to store the information in the database without any formatting (first name, last name, date as utc, no htmlencoding, ...) and have the UI take care of the formatting. If a type of formatting is used often, or if the formatting takes a lot of CPU then i'll cache this formatted data (memory or database). – the_lotus Nov 20 '13 at 15:39

5 Answers5

15

Great question. I do a layered MVC-inspired architecture.

BACKEND

I model (format) the data on the backend in accordance with it's 'natural' order. In other words I follow the internal organization of the data. This is because my APIs are often used by multiple, changing or evolving clients and rewriting the API multiple times or having multiple versions takes too much time to maintain.

This doesn't mean you should send the contents of the database with every API call. You should definitely pare down the data model with for each call but it should be a pared down version of the backend ('natural') data model not a data structure that is customized to a particular view.

FRONTEND

In the front end I have a tightly coupled controller which receives the data from the server and transforms the data into the model that fits well with a given view. Depending on the technology used on the client side there may be library support for this (e.g. AngularJS for javascript/HTML Swing for Java, WPF for C#, etc. etc.)

I find that this architecture results in clean separation and high productivity.

Guido Anselmi
  • 3,872
  • 8
  • 35
  • 58
8

It really depends on the nature of transformation you need to do with your data and also on how frequently a certain type transformation is needed.

I'd make the backend return the raw data by default, but for particular data formats that are often required by the frontend, I'd make the backend endpoint accept a request parameter that tells the backend in what format it should return the data.

marekful
  • 14,986
  • 6
  • 37
  • 59
8

I deal with this with another dev I work with. He loves working in SQL, and does basically everything there, business logic, formatting, etc. Bugs me to no end. In my opinion (and at least for the apps we work on) SQL is for handling data storage and retrieval, server code/client code is for presenting the data to the user and dealing with the user's interactions with that data.

This isn't limited to just SQL (or other DB engine) vs. your application code though. In instances where the server code is more of an API, handing data to a javascript heavy web application, the same thing applies. The API doesn't know what the UI might want to do with the data, the API's purpose should be to deliver raw data, and let the javascript/presentation code deal with formatting it in the required manner.

I'm sure there are exceptions to this, but that's the general rule I like to follow. Formatting is in the realm of presentation, not business logic or data-retrieval. Keep it there.

EDIT: I reread your question and I think I missed a subtle but crucial point. If you have a constructor or model or what-have-you that's expecting an input in a particular format, it might be wise to do that formatting/conversion in SQL to avoid the extra step of converting the data before you can use it. It will depend heavily on the problem trying to be solved though, and the specifics of where the data is coming from and where it's going to be used.

BLSully
  • 5,929
  • 1
  • 27
  • 43
2

Another aspect to be considered is locale-awareness (thousands separator, comma separator, date format, etc).

If the consuming application is meant to be accessed from clients that are locale-aware (e.g. web browsers), I prefer to push the formatting to the front-end as much as possible. Technically it is possible to send the locale as parameter to the backend API, but modern front-end libraries are typically quite good in handling locale by default that it makes it far easier to do it in the front-end.

Exception to this is when you know for sure that your audience is limited to only one locale.

Aditya Santoso
  • 1,031
  • 6
  • 19
2

I'd like to offer a front-end devs / user experience point of view and example.

Right now, in my front-end, I'm looping through a "raw" JSON object that I received from my API and "transforming" it into a different JSON object that will feed directly into my UI table. Remember while this parsing is happening, the UI is pretty much frozen. As a solution, I may do the "transforming" in the API, and just pass in an object that I can feed straight into the UI table without altering it.

I do see the theoretical problem with transforming on the backend (separation of concern). I also see the problem where it takes longer to build/maintain in the case where some other UI component needs that same data but in a different format. But I do believe there is something to be said for leaving the UI free to not be frozen.

Jar
  • 1,766
  • 1
  • 21
  • 27