Messages' translations in microservice architecture

Question

I work with monolith web application written in PHP that is being migrated step-by-step into microservices. I would like to keep the same UI with several new features that have been implemented during the migration. Currently, new elements of the app are written in Angular and they communicate with microservices' via REST APIs to retrieve data and display it on the UI. Since the backed is split onto several instances with their own responsibilities, frontend is still in "monolithic style".

The application is translated into couple of languages and I started to think where to keep texts' translations? Is it still a microservice's responsibility (client asks for this concrete part's translations) or should I move it into client, where the UI is implemented (the frontend knows how to translate things from all data sources)?

If so (or not), why?

Thanks for any suggestion!

Answer 1

There is no right or wrong answer; it depends entirely on the requirements.

Ask yourself, what do microservices provide, and who is in charge of translating pure data into humanly-readable format including text?

Let's take a basic example of an app which simply says hello to a user. However, in order to do that, it needs to call a microservice which returns the person's name based on her ID.

• The first approach is to make the microservice responsible of the data, and put the consumer app in charge of the presentation. The web service will simply return:

  {
      "first-name": "Jon",
      "last-name": "Skeet"
  }
  

  while the web app will embed this response into a template and pass it to the view which, ultimately, will turn it into a nicely formatted HTML saying:

  Hello, Jon Skeet!

  or, if the user appears to be using a French interface:

  Bonjour, Jon Skeet!

  Benefit: your models remain uncluttered, the actual, translated text being applied as the last step. The models can be cached independently of the culture of the user.

• Or maybe the microservice itself knows how to welcome different persons. Some would be greeted in English, others in French; maybe some users won't even be greeted at all, because they haven't paid their bills, and others would receive a warm welcome, because they have a VIP status.

  In this case, the microservice will rather return:

  {
      "first-name": "Jon",
      "last-name": "Skeet",
      "greeting": "Welcome back, Jon Skeet!"
  }
  

  The web app, on the other hand, would simply pass the /greeting value as-is to the view in order to be shown to the user.

  Benefit: content can be customized depending on the information available to the microservice. Otherwise, the microservice would be forced to provide this information to the consumer, while making consumer's logic more complex.