WIQ Documentation

The following technologies have been used to develop this project:

The application is organised into microservices, making the different components that form the project more isolated and easier to maintain, having modules that have less coupling between them, making them more independent.

When the users starts a game, it does so via the game service (which internally will use the questions service). The game service will provide questions until the end of the game.

Other services can ask the questions service to generate a question, this serves as an abstraction over the WikiData API as we are only interested in the questions and not the raw data.

The user can look at his history via the User data microservice which provices access to all of the data of the user.

We have decided that our architecture will be based on microservices, which means that every part of the aplication will be divided in a service that performs a specific function. The services can communicate witch eachother using their repective APIs or via the shared database

The application will consist of a website where the user will be able to play our WIQ game, however as we have not started coding yet we do not have a clear idea of how it will look or if we are adding extra functionality to the webpage.

The application will include a system to control the user access to keep track of their games (And other data), this system will work be based on the token pattern rather than the session pattern. For now we have decided to use JsonWebToken for the token generation and validation

The persistence between the many microservices of the application will be dealt with using a SQL relational database (Specifically MariaDB) which will help to communicate and sync the different microservices

To ensure customer safety we will store their password using a password safe hash such as bCrypt

In order to avoid errors in our aplication we will include a bunch of tests that cover both the frontend and backend areas. (With special attention to e2e tests, unit tests and integration tests)

At this point of the proyect we are not sure if we will implement Internationalization, it’s a decision that we will take as the proyect progresses.

Each component has its own unit tests that verify its functionality acts correctly, thus providing security and robustness to the project.

With acceptance tests, we aim to automatically verify that our system meets the requirements, confirm the integrity of our system with Wikidata, and detect any unexpected issues that may arise unnoticed.

Load tests measure performance in advance of normal load or peak load. To carry out these tests we have used the tool Gatling, which allows to record an example of use and change the amount of load on it.

As one of our quality goals is performance efficiency, we have focused our tests on measuring the performance of our question cache, which we explain in our ADR: ADR 11.

The first step was recording the start of a normal game to see how it loads the question. We will add all the results we got from Gatling in a folder in the documentation section, in case you want to consult it in depth.

This is part of the code that it generated:

As we are quite confident in our cache, we will start with 100 current petitions:

As you can see in 2 seconds we can manage 100 petitions without failing any requests. The same happens with 200 petitions which only takes 3 seconds.

The problems start around the 500 petitions where some requests start fail due to time out exceptions, however around 80% of the request finish correctly and it only takes 10 seconds to finish.

We consider that been able to put up with more than 200 petitions at the same time is a quite good result. We have made more load test, for example load 500 petitions distributed in 20 seconds, which has great results.

And also load 1000 petitions during 30 seconds which was pretty fast, however some of the requests failed.

And to finish with those related to the cache, we have included int the code some of the options that Gatling provides and mixed them. The code for the las simulation is atOnceUsers(200),nothingFor(5),rampUsers(500).during(20),constantUsersPerSec(30).during(15).randomized(). Which at first loads 200 petitions at once, then waits for 5 seconds, loads 500 petitions distributed in 20 seconds and finally loads 30 petitions constant during 15 seconds at a randomized interval. In this graphic we can analyze that the problem with this tests is when the 500 distributed petitions and the 30 constant petitions.

The other part that we have considered important to measure is the time which take an user to login, we have made this process slow because it helps to avoid brute force attacks. As you can see in the test a single user takes 12 seconds which is more than 500 petitions to the game service.

We have consider that usability is one of the most important aspects in a game because people external to the project can see problems or design mistakes that we may overlook. For that reason we have consider advisable to make usability tests.

As we had to develop this project in such a short time we didn’t have time to make proper usability test, for that reason we will take as a reference the chapter 9 of the book "Don’t Make Me Think" ,written by Steve Krug, named "Usability testing on 10 cents a day".

We have tested 6 different users which we have organized in three groups (2 per group) : the ones which also study our degree, but are in another projects; the ones who have high computer expertise because they study something related to technology and the ones who hardly use a computer.

Before the test we gave the each participant a brief explanation about the game, but without going into much detail because we wanted them to discover the functionality of the game.

We have summed up the main negative aspects that each user stood out, however in general they liked the application and enjoyed playing, and group them in the groups we have explained before.