2

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!

  • Did you consider a microservice for texts/translations? It could handle: get(first-name, EN) -> returns a text, if not available it can log a missing translation in the translations tool. It can receive new translations from your translations tool etc. You could also tag them per view, so you could do: getForView(homepage, EN) which would deliver a json with all texts for that view. The responsibility of a data microservice is not to handle translations so in basic it should not do that. It should also not be aware of the current language, unless relevant for business like the greeting example – Luc Franken Aug 31 '16 at 10:17
3

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.

  • Sorry for the delay with the "check" mark and thank you for the response :) I was afraid that there can be an answer like "that depends". But I think I understand the difference. Thanks a lot! – Kuba T Oct 2 '16 at 18:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.