Skip to content

Software Achitecture

Document Software Architecture
Author(s): Noora Kuikka
Version: 0.5
Date: 22.02.2024

1 Introduction

This document provides an in-depth exploration of the software architecture underpinning the Tukko project. It serves to explain the frameworks, technologies, and methodologies employed throughout the project lifecycle. Additionally, it sheds light on the platforms utilized for testing, development, and deployment.

1.1 Purpose and coverage

This document is intended for stakeholders and other interested parties in order to provide a deeper insight into the project system structure, functionality and development process. Within we will describe the Tukko product environment, hardware/software requirements, and frontend/backend architecture.

Additionally we will briefly describe the methods and technologies utilized for the implementation of the chosen features.

1.2 Product and environment

The product name is Tukko, short for Tukko Traffic Visualizer. Tukko is a full-stack web application which aims to provide users with an intuitive way to visualize traffic data in Finland, Sweden and Norway.

The Tukko project is running on the cPouta cloud computing platform developed by CSC (IT Center for Sciences). The frontend and backend will be deployed on two separate Ubuntu virtual machines within a cPouta subnet, protected by a ModSecurity firewall.

1.3 Definitions, notations and abbreviations

CSC: The IT Center for Sciences, a Finnish non-profit enterprise focusing on research, development and technology services. Owner of the cPouta platform.

cPouta: The cPouta Community Cloud service is an IaaS (infrastructure as a service) cloud computing environment. It allows users to host virtual machines running on different sets of compute node hardware, and allocation of resources based on the intended use case.

Virtual machines can be given external IP addresses in order to be accessed directly from the internet, and managed through a web interface accessible via a browser.

1.4 References

To be added later.

2. System Overview

2.1 Hardware requirements

The Tukko project is separated into frontend and backend Docker containers, utilizing approximately 140MB of RAM. The virtual machines utilize 1000MB of RAM, 4 VCPUs each and 80GB disk space.

2.2 Software requirements

The project software runs in Docker containers, and should not require any specific software requirements apart from the ability to run Docker containers.

2.3 Hardware environment

The hardware environment is hosted on CSC's cPouta cloud computing service. A virtual NAT-enabled router acts as the gateway between the virtual machine subnet and the external internet. No additonal hardware will be required for the project.

2.4 Software Environment

The virtual machines run Ubuntu 22.04 as their operating system. The frontend and backend have been dockerized into containers utilizing the following frameworks and services:

Frontend

REACT

  • React is a popular JavaScript library for building user interfaces, primarily for web applications. React allows developers to create interactive UI components that efficiently update and render in response to data changes. It utilizes a component-based architecture, where each UI element is represented as a reusable component.
  • The frontend has been build using React and Typescript.
  • We will use these same technologies to implement features such as the ability to compare LAM stations and user-interface improvements.

VITE

  • Vite is a modern build tool that aims to significantly improve the development experience for web applications, particularly those built with JavaScript frameworks like Vue.js and React.

NGINX

  • Nginx is a high-performance web server and reverse proxy server known for its efficiency, speed, and scalability. Nginx excels in handling large volumes of concurrent connections while consuming minimal resources. It's widely used as a frontend proxy server to distribute incoming web traffic across multiple backend servers, improving performance and reliability.
  • In this project Nginx is utilized to serve the Tukko web application to the users accessing it from their browsers.

Backend

NODE.JS

  • Node.js is a runtime environment that allows developers to execute JavaScript code on the server-side. It uses an event-driven, non-blocking I/O model, making it efficient and lightweight for building scalable and high-performance applications. With Node.js, developers can create various types of applications, including web servers, APIs, and real-time applications.
  • The backend has been built using Node.js.

EXPRESS

  • Express is a lightweight and flexible web application framework for Node.js. It simplifies the process of building web applications and APIs by providing essential features like routing and middleware support. With Express, developers can quickly define routes and handle HTTP requests and responses, focusing more on building their application logic rather than dealing with low-level server operations.
  • Express will be used by the backend to serve Digitraffic data to the frontend.

MONGODB

  • MongoDB is a popular NoSQL database that stores data in flexible, JSON-like documents instead of traditional rows and columns. It offers high scalability and performance, making it suitable for handling large volumes of data and real-time applications. MongoDB's document-oriented structure allows for easy data manipulation and schema flexibility, enabling developers to quickly adapt to evolving application requirements.
  • The project uses a MongoDB database to store older traffic data over a longer period of time.

REDIS

  • Redis is an open-source, in-memory data store known for its speed and versatility. It primarily functions as a key-value store, where each data entry is associated with a unique key. It supports various data structures such as strings, hashes, lists, sets, and sorted sets, allowing for efficient storage and retrieval of different types of data. Redis is often used for caching, session management, real-time analytics, and messaging due to its high-performance capabilities.
  • Redis is used when the user requests live data, or more recently archived data, to ensure quick response times.

Additional technologies

DOCKER

  • Docker is a platform that enables developers to build, ship, and run applications in containers. Containers are lightweight, portable, and isolated environments that encapsulate an application and its dependencies, making it easy to deploy and manage software across different environments.
  • The frontend and backend will both run within docker containers.

MODSECURITY

  • ModSecurity is an open-source web application firewall (WAF) module that runs as an Apache, Nginx, or IIS module. It provides protection against various attacks on web applications by monitoring and filtering HTTP traffic in real-time. ModSecurity can detect and block common web application vulnerabilities such as SQL injection, cross-site scripting (XSS), and remote code execution. It offers flexible rule sets that allow customization to suit the specific security needs of an application or website.
  • We will utilize ModSecurity to implement a web application firewall to protect both the frontend and backend servers.

ZAP

  • OWASP ZAP, short for OWASP Zed Attack Proxy, is a popular open-source security tool designed for finding vulnerabilities in web applications. It acts as an intercepting proxy, allowing users to observe and modify the HTTP and HTTPS traffic between their browser and the target web application. ZAP provides a wide range of automated scanners for detecting common security issues such as SQL injection, cross-site scripting (XSS), and broken authentication. It also includes various tools for manual testing, session management, and fuzzing.
  • We plan to use a dockerized version of ZAP to automate vulnerability scanning.

GITLAB SECURITY DASHBOARD

  • The GitLab Security Dashboard is a tool that gives an overview of security issues in projects. It shows things like vulnerabilities in code, any problems with dependencies, and issues found in containers. It helps you keep track of these issues and fix them to make your projects more secure.
  • We plan to utilize the Gitlab security dashboard when hardening the Docker containers and implementing secure coding practices.

3. Description of the Architecture

The initial design for the deployment diagram can be seen below.

Deployment Diagram

  • The application will be running on cPouta's cloud computing platform within its own subnet.
  • A virtual NAT-enabled router will act as a gateway to the rest of the internet.
  • cPouta's own firewall rules will act as the first layer of protection within the network.
  • The frontend and backend will be on separate virtual machines. Only the frontend will be accessible using an external IP address, to access the backend, we will first need to ssh into the frontend and then access the backend utilizing its internal IP address within the subnet.
  • Both the frontend and backend will be protected using the ModSecurity web application firewall for additional layers of security.

3.1 Design principles

As cyber threats are becoming increasingly sophisticated and prevalent, adopting a security-centered approach to feature implementation is crucial. By prioritizing security in our design principles, we aim to safeguard sensitive data and protect our application from potential vulnerabilities. Implementing strict role-based access control (RBAC) ensures that only authorized users have access to specific resources, mitigating the risk of unauthorized access or data breaches. Embracing the principle of least privilege further enhances security by restricting user permissions to the bare minimum required for their role, minimizing the potential impact of security incidents. By avoiding unnecessary dependencies and conducting regular dependency checks and code reviews, we reduce the attack surface and fortify our defenses against potential exploits or vulnerabilities.

In addition to security considerations, designing a user-friendly interface based on the Web Content Accessibility Guidelines (WCAG) version 2.1 is essential for ensuring inclusivity and accessibility for all users. Accessibility is not only a legal requirement in many jurisdictions but also a moral imperative to ensure equal access to information and services for individuals with disabilities. By adhering to WCAG guidelines, we prioritize usability and strive to create an inclusive digital environment where users of all abilities can access and interact with our application effortlessly.

This commitment to accessibility not only aligns with our ethical principles but also enhances the overall user experience, driving customer satisfaction and engagement.

4. Ideas for Further Development

If we have time, we hope to work on additional features within the backlog. These include:

  • User accounts and authentication
  • Securing traffic over HTTPS
  • Implementing rate-limiting on the API endpoints
  • Hardening containers
  • Web App Accessibility Measures
  • Compare LAM Stations