KaW Docs

One of the things to increase accessibility is giving our application the capability of being in various languages so people around the world can play our game. Obviously, internationalization is more than just changing the language of the Application but due to time constraints we will just offer Spanish, English, Ukrainian and French languages ( although, our API can generate questions in other languages different from described, to see the whole list, refer to our API documentation ).

The library used for language translation in our KaW game is called react-i18next. For simplicity (and due to just only having three languages), all of the translations of messages are stored locally in properties files. Eventually, if the Application grows and we wanted to have more than 4 languages the best approach is to store those properties in a server and let the application to request those on the fly. Again, for simplicity the option of having all bundle together in the Frontend just fits.

The translation of questions is a bit different from the frontend part since it is done "on the fly" by using the Microsoft translation API . This change has been done since the questions are not fully known until they are generated so storing the translation locally does not provide any benefit. Also, one advantage of it, is its simplicity and ease to use. To meet the restrictions impose by the Free version of this API a series of formatting rules are carried out into the question generation phase to minimize the usage of it and avoid getting suspended.

Keeping a secure website for our users is one of our main quality goals. For that, all the passwords stored in MongoDB are simply hashes so attackers cannot decipher them easily. The library used in the AuthService and UserService to store or compare passwords is called bcrypt. This library provides with an easy way to hash passwords and keep user’s data secured.

Also, all users are enforced to have a password with at least 8 characters. This security measure makes a lot of sense if we want to really ensure the security of our users. Although sometimes it could be a bit cumbersome for some, the introduction of this measure make security to grow exponentially.

To keep our users' data secure an authentication mechanism has been developed with the use of JSON Web Tokens (JWT). If someone tries to access historical game records for certain users, our KaW application enforces to pass a valid token through the header of the message request.

In this way, only authenticated users are able to consult the different data that our application enforces.

As stated in the quality goals, the security plays a crucial role in our application to prevent any attacks from external users or any potential backdoors that we could have in our code.

For that, a Static Application Security Testing (known also as SAST) tool is included into our project. This tool scans the source code of our application for security weaknesses, potential vulnerabilities, and coding patterns that could lead to security breaches. One famous service that implements a SAST is SonarCloud, so the team has decided to use this tool in our CI and CD environment so each time a change is uploaded, the security scanner checks for any issue.

Testing is one important feature when development comes to the table. To keep a good CI and CD environment a series of tests are enforced before submitting any new change into our main pipeline project. GithubActions help us to achieve this goal where different workflows have been built to ensure a project with the highest quality standards.

There are many different types of tests and the team has decided to enforce the following ones:

Each new code is tested independently to ensure its correct functionality and not breaking the main project. The testing framework used both for Backend and Frontend is Jest due to its simplicity and its great bound with Javascript files.

Also, the usage of SonarCloud gives us more than security checking, it also enforces each member of the team to have a good coverage on our code to meet the quality standards we are required.

Apart from testing functionality, all our code must also meet the required domain functionality such as registration, login, etc. For that, Jest is used in combination with puppeteer which provides a High-level API to control browsers and simulate our different User Stories (domain functionality) that the project requires.

The following functional requirements have been tested:

The combination of both Unitary and End-to-End tests gives our Application with enough robustness to meet the expectations of delivering high quality code.

Although our application may not have a huge load of users, one of the quality goals is the performance of the application. With load testing, the team will be able to identify certain aspects or cases in which code takes too long to execute things. For example, having a lot of users playing the game and making a lot of requests to generate questions.

For that, Gatling was chosen as our main load testing framework. Although, it is not written in Javascript which could facilitate the configuration, Gatling offers a light and simple framework to build these kind of tests. Also,the files generated by it are Java files which eases the tasks due to the vast knowledge of the team on this programming language.

To see a real workload and how our application behaves to it, it has been carried two different tests per each case scenario. The first one could be consider a "considerable" amount of users where 20 users arrive to the application per second during 60 seconds. The second one is a type of load testing called Stress testing where the Application is put at its maximum capacity so it breaks. The following results are provided below:

As it can be seen, the Application runs smoothly with 1200 concurrent users and it is more than enough to meet the quality requirements and taking in mind where the Application is hosted. On the other hand, it is currently impossible to achieve availiability and performance if 3000 users use our Application.

If more information is needed on how to run those tests, please go here.

Finally, another crucial part to be tested in our application are usability ones. With these test, the team tries to deliver high quality functionality to the users by simply testing with them and examine its behaviour.

The team will select different people to try our application to get Information on how to improve it, at the end, this application is for them!

Usability testing does not ends here since it is needed a real one with lots of users of different ages and also, taking into account its timing on completing certain tasks. Although, taking already care of these details makes really the difference.

Google’s automated tool LightHouse is used to perform several of "cross-cutting" tests to improve the performance and correctness of our web Application.

It has been tested each page of our Application against this tool to see any flaw into our application, and, as it can be seen, our game has a very good mark on each one: GamePage, HomePage, LeaderboardPage, LoginPage, ProfilePage, RegisterPage.

The reason behind, is that with Microservices architecture we can forget about dealing with a single complex application. Instead, we make a "Divide and Conquer" approach by identifying those modules that made up our system and making it independently deployable services, each serving a specific business function.

This architectural pattern makes it easier for the Frontend subsystem to communicate with the different MicroServices that composes our Application since it has to focus on a single entry point instead of knowing which service to consult. It also help us to tackle the requirement of APIs by using this pattern since it acts like a REST API where other users (not our Application) can make petitions to it to retrieve some data using a uniform interface.

As stated in point 4.1, the chosen database for the project is MongoDB which offers us a document-oriented schema. This type of database fits perfectly with our services since the mainly work with JSON-formatted data.

To handle the different sessions of our different users, JWT are also used for this purpose. For each logged in user, a token will be generated for authenticating them as stated previously, and also, for maintaining a session and hold the necessary information without having to reenter the users' credentials. In this way, the user will have to keep on its browser this token to maintain alive the session.

To provide with quality to the Application, a monitoring system has been applied using Grafana and Prometheus,to always keep track of how the application is performing. The work is simple, it has been added Prometheus to "scrap" information from the Gateway Service like all the petitions it is asked to it.

This information is available at kawgame.xyz:8000/metrics and the Prometheus application, that manages it, at kawgame.xyz:9091. Although, this is retrieval is good, for the "humans" is not so comfortable to the "eye". For that, Grafana has been set up.

This application help us to see in a graphical way all the load that our Application is having and how it responds to it. As this is "developers" information, a login has been set up to prevent other people from knowing this information.

In that way, we would have the following:

As requested by our shareholders, the application needed to keep all data from previous deployments. For that, the team has decided to have a simple yet powerful solution with the usage of Volumes of Docker.

With this approach, each container from the Infrastructure shown before has its own data stored in those Volumes and it is also independent from it, so any new release will use the previous data and "persist the persistence".