6

I am a backend developer and was having this argument yesterday with a frontend dev in my team about whether or not should I let him fetch the displayable text message about the result of an operation from the backend.

My argument was that since it is a presentation layer decision, it should remain with the UI. They should switch on the response codes agreed upon between the backend and frontend and show the text messages accordingly. That way, the backend can also stay unaware of the interaction between the UI and the user.

Actually, since my company is extremely backend heavy, the practise here is to keep the UI extremely lightweight.

But I want to take suggestions from the community here to understand whether it is a good practice to retrieve the display messages from the backend or not.

In my small career as an Android fullstack developer (before this company), I always believed that the interaction between UI and backend should strictly about the data and not the presentation.

Rajan Prasad
  • 169
  • 3
  • 3
    It seems like a useful question for a lot of people. However, answers are going to be very dependent on project circumstances, requirements, and opinion. Also some might want to know if you are speaking of error messages or just output text in general. – joshp Feb 12 '19 at 05:08
  • 4
    This depends a lot on unknowns. How hard/time-consuming is changing the frontend when messages change? How often are messages added/changed? Is localization involved? At the end of the day, a solution must be viable given the development and support constraints of your company, and theoretical beauty is only secondary. – Hans-Martin Mosner Feb 12 '19 at 06:54
  • @joshp Talking of output text in general. – Rajan Prasad Feb 12 '19 at 12:55
  • @Hans-MartinMosner, whatever changes will be required in front end will be required in backend as well when a new feature is introduced, isn't it? With that in mind, shouldn't we keep the data strictly separate from presentation always? – Rajan Prasad Feb 12 '19 at 12:56
  • Whether frontend changes are necessary depends on the particular backend changes. Consider an app that lets you choose between different third-party services (e.g. stock market or weather data). Now a new provider interface is added to the backend. If the frontend requests the list of providers from the backend and receives provider specific messages from the backend, too, it does not need to change at all. – Hans-Martin Mosner Feb 12 '19 at 14:08
  • @RajanPrasad it's quite possible for changes to be needed that are purely textual. For example I've recently completed a change to one of our systems that was prompted by a change in branding brought about by trademarking requirements. It involved only changing the name of the product in messages being displayed on the frontend. Because of the way this system was designed it required making changes to both frontend and backend code. Another design might have required changes in one or the other only. – jwenting Feb 13 '19 at 04:52

1 Answers1

6

I guess there is no definitive answer in favour of one or the other, it heavily depends on many factors. Some of them may be answered objectively or because of business requirements, some of them are subjective or a matter of taste.

Here are some of these factors that come to my mind (in no particular order; some points may overlap with others):

  • How smart or dumb do you want your frontend to be?
  • What is the overall architecture of the system?
  • Does the framework you use already provide a mechanism for storing/managing messages? Do you want to use this mechanism or do you deliberately choose not to use it?
  • Do you need different texts for different users (e.g. translations)? Does the frontend know about the users preferences (e.g. language)?
  • Are there other similar things (like different currencies, taxes, units, logos/images…) in your application? Are they located on the backend or the frontend side?
  • Will there be more than one frontend (e.g. an app and a website)? Do they need to have a consistent wording (i.e. messages belong to backend) or should the texts be different for each frontend (i.e. messages belong to frontend)?
  • How often do you change your messages? Does this better match the deploy times of the frontend or the backend?
  • If you develop new features at the backend requiring new messages, is it ok (or already necessary for other reasons) to deploy a new frontend version or should your frontend be flexible enough to support those features without modification?
  • If you redesign your user interface without adding any new feature at the backend side, is it ok to deploy a new backend version just to adjust your messages accordingly?
  • Maybe it makes sense to split your messages and locate some on the backend side and some on the frontend side? Or potentially even a separate "messages microservice" is reasonable in your case? (But mind the drawbacks of such solutions, like additional complexity and overhead and maintenance difficulties!)
siegi
  • 292
  • 1
  • 3
  • 6