Moving to microservices: i18n @ COYO Part 1
COYO, being a software that was rapidly developed over the course of multiple years, is currently not only facing the challenge of a growing code base but also of a growing team, well beyond 25 developers, working on the same project. At the same time, the international expansion of the company itself asks for more languages to be supported in the product, next to German and English. Adding these to an already heavy frontend did not seem like a feasible option. Therefore the decision was made to introduce a central internalisation service that provides message key bundles for all services.
Follow our story in this two part series, on extracting the first service out of the existing product. In the first part we are going to focus on extracting the bundles from the other services into a central “key store”.
As mentioned before, the main goal was to provide a central store for all message key translations that delivers all interface translations in a single call for a dependent service, in a format that can be presented to the user without the need of any calculation - think of necessary fallbacks to the system language or English.
Coming from a monolithic application engineered with Spring Boot 2 and a frontend application that is gradually moving from AngularJS to Angular, the general skillset of our development team can be pinned to JavaScript/TypeScript and Java. The possibilities with these languages are nearly endless but can be narrowed down to the following popular frameworks, in the early state of the microservice transition that we are in:
- Spring Boot
- NodeJS with Express
- NestJS
To have a very lightweight application with typing support the decision was made for NestJS as it provides typing (via TypeScript) with a Spring Boot like application architecture on top of Express + NodeJs and provides a fast learning curve for all developers of a team being frontend or backend.
After deciding on the technology and setting up the project including CI, health checks, logging, management endpoints, the goal was to move the existing message key translations from being bundled into the frontend application next to the actual components to one central file that is delivered by the new service.
While the implementation is rather simple as we just needed to remove all the files and merge them into a central one and then statically serve it from a NestJS controller (Figure 1). The benefit of this is mainly visible on the second look, as it not only removes 1.5 MB of message keys from the frontend bundle but also made us introduce a central workflow tool (Zanata) to work with translation agencies.
A central tool also allows developers to only work on the English translations in the project and each change is automatically pushed (Figure 2). All other translations are pulled from Zanata (Figure 3). A major benefit especially to international colleagues that do not speak German (the second supported language at that point) is the possibility to add more languages easily in the future without the need of code changes.
At that point the first version of the service went live and already served the bundles for the frontend and in a second step for the backend components (e.g. push and email notifications). Still we haven’t reached our goal yet as there are still multiple calls and calculations needed in the frontend to present the user language, as the product allows every customer to overwrite each single translation for all services and these are still residing in the monolith.
That fact needs a lot of technical ground work due to the needed data synchronisation between services. To see how we coped with this challenge, stay tuned for part two.
