This project consists of an express rest API server written in Typescript. It's a cloud-based application. It's built with different microservices developed with Node Js, Docker, NGINX, MongoDB and MQTT.
This application is the result of the continuous research of the telemetry group from 2018 until 2021. The result is a maintainable application to serve the telemetry web-app used by the member of the team. The main focus is to serve the web app by giving the data to render the charts of the vehicle during the tests. Each user should have the possibility to see a customizable page with charts and configuration of the vehicle. Further user stories could be implemented starting from this zero version of the software.
-
Fix Tests :(((
-
Fix port from config
-
MongoDB Paging [Guide] (https://scalegrid.io/blog/fast-paging-with-mongodb/)
-
Typedoc
-
Swagger to NGINX Configuration [Script] (https://gist.github.com/nginx-gists/37ce65292a06219ff8d35d293c05e0b5#file-oas2nginx-sh)
-
Heroku CI
The web app mockup is designed according to the feedback gathered via a questionnaire in 2019. Other interactions are required to validate the usability and the complete set of functionalities needed for tests and race events.
The template used to build the microservice architecture is described above. It consists of five main folder:
- loaders: to inject dependencies, routes and all sort of configuration.
- routes: where the route of the API are described with the swagger code. It also has a controller.ts to handle requests.
- controllers: it's where the magic is, all the sauce of the project. This folder contains all the functions used to retrieve data from the database or to interact with external API.
- tests: it runs the application as a different process in order to test newman requests.
- config: with the index.ts it's possible to load all the .env variables, it's based on the environment (test or production)
NGINX is an open-source web server that also serves as a reverse proxy and HTTP load balancer. As reverse proxy it sits in front of our microservices and API Gateway. When a browser makes an HTTP request, the request first goes to the reverse proxy, by checking the API Key for the user, which then sends the request to the appropriate microservice. It is straightforward and lightweight, but in future the authentication process will be handled differently.
The API Gateway is responsible for request routing, composition, and protocol translation. All requests from clients first go through the API Gateway. It then routes requests to the appropriate microservice. The API Gateway will often handle a request by invoking multiple microservices and aggregating the results. The api-docs is also available here.
The History microservice is used to serve the web-app with all the documents, data of the vehicle. This microservice consists of and adapter layer to get the information from a schema-less database (MongoDB on Atlas and inside the University of Trento) The api-docs is also available here
The Airtable microservice is used to serve the web-app with all the information about the user and their personalized views based on their role. This microservice consists of and adapter layer to get the information from a Airtable. The api-docs is also available here.
The Views microservice is used to serve the web-app with all the information about the personalized views based on the user role. This microservice consists of and adapter layer to get the information from a Airtable. The api-docs is also available here.
The Live microservice is used to insert the documents/data sent from the vehicle. This microservice consists of proxy for the messages receive on the vehicle topic. The broker is broker.mqttdashboard.com. The api-docs is also available here.
The MQTT Publisher microservice is to intend as a test service to emulate the condition of the car which is sending data to the online application.
Clone the repository, install the module and place the .env file with tokens and variables.
Place the .env file in each root of the microservices.
The test file should be called .env.test and it's used during local tests.
.env
PORT=3333
DB_NME=dbname
DB_HOSTNAME=<insert-your-connection-string>
In the root folder run:
docker-compose
npm start
This command should build and run the microservices with the reverse proxy, each route is accessible right now. Further development will only expose the client routes in order to serve the web-app.
Eache microservices have several npm scripts, the description is below:
npm start- Start the app with nodemonnpm transpile- Transpile the typescript file to javascriptnpm commit- Commit with commitizennpm commit:sign- Signed commit with commitizennpm test- Transpile the application and run all the tests
To run each microservice alone for development purpose build and run the image as described below
docker
docker build -t 'microservice-name' .
docker run 'microservice-name'
The complete generated document of the API is available here. It's possible to check the documentation of each microservices on the route /api-docs
The report is in the /documents folder