So I'm having a discussion with frontend devs now and I'm curious how you folks are doing this:

suppose you have a rest api at BE and some js framework in FE consuming it. Where do you format display info at: BE or FE? Info like human-readable timestamps [according to user's TZ], i18n, displaynames with appropr. lengths, etc..

Is this a job for FE or BE in your oppinions?

[imo it's view's job to be responsible for view-speciffic matters, while BE should provide all required info for FE to do it's formatting et al.]

Back-End gives the raw "Data" and Front-End should extract "Information" from it in required format .

I usually prefer more towards the BE except I'll usually layer out the API response and do any transforms that I need to in the mapping service or adaptor.

From time to time if the view is heavy enough I'll layer out a response specifically for the view in question from that API. Those instances are pretty rare.

Depends on your architecture I guess, and if you see a problem in serving different payloads to different users for the same BE call (excluding headers). Offloading the view-related work to the client does mean your servers do less work, so there's an advantage there.

Another benefit of doing it client side is if you send localized data instead of ISO and the user didn't want it in the format you assumed they would, if they want to change it they'll have to send another request instead of having the FE reformat the iso data.

@spongessuck I can also chime in. A date that doesn't change and is frequently presented, can be cached on the client side.

I suggest that BE is the single source of truth, and has for example:datetime as UTC strings passed to FE, then based on the timezone of the browser(system) it accounts the TZ and for the human readable format, highly suggest to check this article ( in case of Datetime):

http://apiux.com/2013/03/...

Very well. Since my opinion is the same as majority's in this thread I can rest assuredbI was not crazy to ask FE to do all those things. Considering amounts of resistace I got...

@netikras It might not be that you're asking them to do the formatting for display. But maybe that you're just asking them to do extra work. No one likes doing more work then what they have to do.

@netikras Depends on who you ask I guess. Backend wants to do everything, frontenders wants to do everything and if there is a cloud service in the picture, the guys paying wants frontend to do everything.

I had this same chat with my co-workers.

BE is like a Vending machine: you want what cookies, they are in A1 position, you pay and do the request pressing A1 for it.

Then the vending machine deliver the cookies to you. Thats ALL the work should do the vending machine (BE)

Asume that A1 have cookies with chocolate drops.

It is kind dumb that he client (FE) yell to the vending machine "hey! I hate chocolate drops, get them off" or "I don't need them remove it" or even "I just want the chocolate drops".

If client do not want / need something from what it get, remove it, ignore it or change it, but those cookies is what you get with that request.

I think there’s a room for two types of backend: backend as an api and backend for frontend.

The later one may (and usually is) formatting data to be just inserted into page without much modification.

Meanwhile purpose of the first is to give the source of truth

@Rozz Agree

@Rozz and if some time later there is another company abroad who wants to integrate with your app, then what? Spin up a new set of the same APIs, just with different translations/timezones? Or ask that client to re-parse your existing api and re-format, re-translate it? Or rewrite your entire FE and BE API to become FE-agnostic?

I know, it's in the future - it's future's problem. But suppose that 'future' is next month

@devilb2103 Looks like a cool game, I did not create a game when I was a tenth grader. However, this is not the place to advertise it. If everybody got the bright idea of advertising their games and whatnot, I would not stick around.

If you have time, have a look into marketing and social media. People generally don't advertise like you do anymore because they were able to find a better way.

@devilb2103 sorry mate, this is spam

@netikras I’m thinking of different services. API —> BE —> FE. That way integration is not a problem. Currently I’m working at the company that utilizes this approach, internalization is done both on BE and FE, and for integration we’re selling separate API service but at the same time using for our BE

@Rozz so basically spinning a separate api for each integration then is it? :)

@netikras at the core it’s same api, just facades to control access rights and rate. It’s not a silver bullet, but it keeps company afloat

@Rozz Got it. A core app with a set of core APIs and each new integration gets a separate facade/client-api that acts as an individual adapter. That's a nice idea if your company relies on this model :) Considering you have the core-apis designed to be suitable for this kind of star-topology.

It's a kernel pattern I reckon?