Architecture
Our first level of granularity is a Layered-Architecture as follows:
- Google Auth API & Angular Frontend
- NESTjs Backend & MQTT Service
- MongoDB database
A layered architecture was chosen because of:
- Modularity and Separation of Concerns: Layered architectures promote modularity by dividing the system into distinct layers, each with a specific responsibility or concern. This separation of concerns makes it easier to manage and maintain the system. Developers can focus on one layer without needing to understand the entire system's intricacies.
- Scalability and Maintainability: Layered architectures enhance scalability and maintainability. As each layer has a well-defined role, it can be scaled independently to accommodate changes in user load or data volume. Maintenance becomes more straightforward because changes in one layer are less likely to affect other layers, reducing the risk of unintended consequences.
- Security: Security mechanisms can be implemented at specific layers to protect the system. For example, authentication and authorization can be handled in a dedicated security layer, ensuring that these critical aspects are properly managed.
In our event-driven architecture, the frontend page sends requests to our API controller on the backend-server, where those requests are translated to queries and commands. Those queries and commands then trigger their own events, where all the business logic is implemented.
The results are then returned to the controller and sent as responses to the frontend to be used.
The reason we have chosen the Event-Driven architecture is due to the loose coupling of this pattern, leading to more flexibility and adaptability.
When we want to, for instance, limit an event to be accessible to only one role, we create a guard that is triggered when that event is being called.
For the positioning of devices, we also implement event driven architecture: a clock triggers the positioning of devices in our temporary buffer every second. It then also clears the buffer so no duplicate data is found.
We have implemented the publisher subscriber architecture in the hardware side of our project. Here, sensors are all connected in a mesh topology, with only one sensor acting as the connection point to our MQTT server.
The sensor then acts as a publisher, and the MQTT server as the broker and the API, the subscriber. When a sensor wants to transmit new data, it publishes it to its own topic. Then the subscriber receives the information and sends it to the database.
The reason for the architecture is due to its performance and scalability. More subscribers can always be added and the single access point is more performant than having all the sensors send their own API request to the server.