Is the frontend or backend (API) responsible for formatting data in a specific locale?

Question

In our company we had a discussion whether formatting data in a certain locale is the responsibility of the frontend application or of the API that provides data to it.

Which of the following scenarios would be best practice?

Scenario 1

• The API returns data (DateTimes, decimals, etc.) in their original data type (i.e. as DateTime, decimal, etc.)
• The frontend application is responsible for formatting the data that's been provided by the API in the required locale.

Scenario 2

• The API is responsible for formatting DateTimes, decimals, etc. in a specific locale and returning them as formatted strings to the frontend.
• The frontend displays the data (formatted strings) as they are, and doesn't need to take care about the formatting.

Answer 1

Approach 1 – handling formatting in the frontend – is usually the best answer, as once something has been formatted it is less suitable for further processing. If there are multiple consumers in different cultures it is more natural to handle that closer to the point of use. It also saves you having to pass the culture back up to the API, and consequently simplifies the test coverage.

However, in some cases you are obliged to use the other approach (localization in the backend). For example, sorting and pagination - what constitutes "alphabetical order" is culture-dependent, which would appear is, say, the selection of sort order in an SQL query so that the cursor is in the user's culture-appropriate sort order (so that results can be incrementally returned by the cursor, instead of all results returned to the front end, then have the front end reorder all results).

Answer 2

When you think about having one frontend application and one backend, the decision seems to be very arbitrary and both can work.
But the more you have different frontends and backends the clearer it will be that you want to do close to the frontend.

Let look at the example of DateTime:
Imagine you have a train booking website and a backend that gives you the schedule and you decide to put the formatting on the backend in either German, Dutch or English.
Now you add another service that deals with vouchers that have an expiry time. Now you have to duplicate the date formatting functionality on two services and need to make sure that they are in sync, since otherwise your formats will be inconsistent (if your care about such things).
Then you decide to integrate your schedule service with another product which also supports French, now you have to go back to both of your services and have to make them support French as well. Finally you decide to make an iOS, now you provide the schedule through an API as strings, but since iOS has native date formatting your app looks inconsistent if you mix it with other date information that you format locally on the phone.

If you instead choose to return data instead of formatted strings, you don't have to worry about any of that.
Just add new backend services that return times and whenever you want to add a language all you need to change is the frontend application.
You also can have different formats and language support on different apps. Note that when I say frontend application it doesn't necessarily be on the client side. For a website you might want to do the formatting as one of last steps when rendering the server-side HTML.

Answer 3

Rather than getting hung up on frontend vs backend, it would be worth considering what the architecture for your UI looks like.

There are a number of common paradigms for user interface architecture. Model-View-Controller is probably the best known (although the name is often mis-applied to other architectures), with other related paradigms like Model-View-Presenter, Model-View-ViewModel, and the loosely related Flux paradigm.

What most of these paradigms have in common is that they separate business logic (model) from presentation logic (view). They differ in how these components are connected, and what supporting infrastructure assists with this, but that is a key characteristic that they all share.

Assuming you're following a paradigm like this, probably the most important thing to recognise is that culture isn't part of the business logic, so doesn't belong in the model. Depending on your exact paradigm, it might make sense for it to live in the view, or in one of the supporting components (localisation is not an unreasonable thing to handle in a ViewModel, for example), but you probably don't want it in the model.

In terms of web application architectures, there's been a shift in recent years, where the model used to live purely in the backend, but nowadays is more likely to live in the frontend, or at least span the two (and paradigms like Flux attempt to make this more concrete). So depending on your application, it may make sense to put the localisation logic on either side of that divide. But the guiding factor should probably be the architecture. Where is your model, where is your view, what connects them, and what is responsible for what?

Answer 4

While I completely agree with pcj50's answer, there's something else that needs to be taken into consideration and hasn't been mentioned in the other answers:

• Data in its original data type is for processing
• Data in formatted strings is for displaying

If the sole purpose of your API function is to visually present information to an end user, then you can handle formatting on the back-end. But if the same function (let's say a request for a filtered list of information) is used by a tabled view, and a chart view, and on another function that further processes it to generate a summarized report, and also can possibly be consumed from a future application which you don't know what will it do with that data, then formatting has to be handled by those "consumers" that require it formatted.

Answer 5

Both can be suitable for different circumstances.

If you're making a frontend-agnostic API, generally you want to return a machine-readable version of the data and leave formatting to the frontend. When returning dates, you use ISO8601 in UTC, when returning numbers you use regular JSON numbers, etc. For server-to-server APIs and APIs that are going to be consumed by other parties that you don't control, you almost always want to do this. Without any other context on how the API going to be used, this is usually the preferred practice.

However, there are some contexts where returning a pre-formatted data in the API is appropriate. One problem caused by requiring frontend to format the data is that they make the frontend more complex, and for frontend, additional complexity means additional i8n libraries and locale data that needs to be downloaded by the user, bloating the frontend application.

For multi-platform applications, keeping localization in the server means you have consistency on how data is formatted across all platforms, you reduce the size of the frontend, and you only need to write localization logic once.

The alternative that's available for mobile platforms is relying on the platform's Localization API, but these would normally be limited to just simple localizations, like formatting numbers and dates and it may not be available if one of your target frontend is a browser. This can be a a good option if your localization requirement is simple and sufficiently met by the platform's Localization APIs. For more complex localization requirements, like for example, translating error messages and interpolating the values into the error messages, it can be quite complicated to need to build and prepare platform-specific translation files.

Answer 6

Geez. It's nice that so many people are eager to have their voices heard and want to help out with an answer. What's not so great is how long-winded the responses are while almost side-stepping the answer in some cases.

Here's the succinct answer:

1. Your front-end code should handle all your locale and culture-related data formatting. There's many JavaScript libraries for this exact reason. Moment.JS is one such library for handling local datetime formatting.

2. Your backend data should be agnostic meaning it should be as basic, atomic, and generic (non-biased) as possible so that localization may happen easily anywhere. But, more important, data analytics, warehousing, and machine learning (among other platforms) will also be able to use this data more efficiently (than formatted data from an API or DB).

NOTE: Datetime is seeing an overhaul in the JavaScript language to support formatting much easier for locales. Before jumping into moment.js, please refer to MDN for the current state of the JavaScript Date object as well as your browser's console to verify support.