Should data be formatted in the backend or front-end?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.