Technology choices

A tool using a such architecture implies to use existing libraries and technologies in order to complete its mission. In this part we will discuss these technology choices.

Back-end

NodeJS : The use of this technology is fostered by the fact that the tool primarily hosts information that needs to be reached by external (User or Slaves). Also, the easiness of the deployment of an HTTP Server with this language is a strong argument compared to the complexity, formality and rigorousness of a Java deployed HTTP Server. Another argument is the enormous amount of resources and libraries (modules) in NodeJS which are easy to import (Node Packet Manager, NPM and the package.json file) and use.

ExpressJS framework : This library is a NodeJS framework which acts as a RequestHandler in order to handle and manage API endpoints. It already handles requests errors (404 for example) and allows easy management of endpoints and responses to requests thanks to middlewares. Also, it can be simply deployed using the ‘createServer’ method of http module and it listens to incoming requests.

SocketIO : This library is what allows communication between actors of this tool via WebSockets. It is preferred to WebSocket library because, in general, it allows more easily and intuitively the connections between the server and clients. For instance, it allows to create ‘Rooms’ which can be allocated to a certain type of client, for example, when a Slave performed a test, in order to alert all users browsing on the tool, we will simply alert all clients connected to ‘webclient’ room instead of sending to each clients one by one. Moreover, documentation around this library seems more extensive. Another argument is discussed in the Front-end part.

Front-end

Angular : Having a dashboard in order to visualize and exports test results was a requirement in the tool. Thus, selecting an API among multiple, displaying the Slaves status and progression and Charts aggregated with the data implies to manipulate the HTML DOM. Manipulating this object ‘manually’ with its own JS functions at this scale is highly risky and unreliable. This approach fosters the usage of a framework in order to abstract the DOM manipulation and only act on the behavior and the data. The choice of Angular is purely arbitrary, it could have been React.

SocketIO : The argument, which is not discussed in Back-end part, is that SocketIO provides a simple and intuitive API to configure a connection and handle the events. Providing a configuration object in the AppModule of the Angular project is enough, then each services can focus on certain events for their own purpose.

C3 : This is a Chart generation and manipulation library, it is based on D3 library. This choice is arbitrary, it could have been ChartJS.