Skip to content

Software Architecture

1 INTRODUCTION

1.1 Purpose and coverage

This document is for the nerds and developers who care about the nitty gritties.

This document will go over our stack, gives a brief explanation of each technology, why we chose them, and how we are using them.

1.2 Product and environment

Our product is Tukko, short for Traffic Visualizer. Tukko is a full-stack web application that shows general data and hotspots about Finnish traffic.

Tukko is running on CSC (IT Center for Science) servers, where we have a Linux virtual machine instance. As a modern web application, Tukko will support modern browsers for all operating systems.

2. SYSTEM OVERVIEW

2.1 Hardware requirements

Tukko runs across 4 docker containers, taking about 140MiB of RAM when all four are running before too much logging has happened. MongoDB generates the most logs but has limits proportional to the RAM available on the hardware running the container.

CPU must be able to run virtualized software, which in 2023 should be most processors from the last decade.

2.2 Software requirements

As the entire stack is dockerized, all your environment needs is docker support.

3. DESCRIPTION OF THE ARCHITECTURE

Example of Deployment Diagram

uml diagram

3.1 Design Principles

Our team's approach to designing a traffic visualizer centers around three key principles: aesthetics, performance, and usability. Previous iterations of traffic visualizers have fallen short in terms of user experience, with unappealing designs and sluggish performance.

We looked at past projects and know the frustration caused by slow loading times and laggy interactions. Our team places a strong emphasis on optimizing the visualizer's performance by using efficient data processing, caching, and scalable architecture.

It's also important for the application to be intuitive to use. By organizing information effectively and providing clear navigation, we minimize the learning curve for users.

3.2 Software architecture, modules and processes

Frontend

React

https://react.dev/

React is a very popular JavaScript framework that allows developers to create more complex and scalable web applications.

React was requested by Combitech, but the team was also excited to learn React! In the professional field, React has been a main stay for years, so our "value" in the job market goes up for learning React.

Vite

https://vitejs.dev/

Vite is a powerful development server. It has multiple features that make development easy, such as live reload, module bundling and so on.

When building an web application, Vite also makes some performance improvements by converting your entire project into basic HTML, JavaScript and CSS.

Nginx

https://nginx.org/en/

Nginx is an HTTP server that can serve your website to the world. The frontend that Vite builds gets fed to a container running Nginx, which then serves our web application.

Backend

Node.js with Express

https://nodejs.org/
https://expressjs.com/

Node.js is a JavaScript runtime, meaning you can run JavaScript code on your computer like you would a regular program. More commonly JavaScript is limited to running in browsers.

With Express, you can create a server that runs Node.js, and is a very popular solution for APIs. Our backend will serve Digitraffic data to our frontend, and Express is a good tool for that.

MongoDB

https://mongodb.com/

MongoDB is an object-based database solution and is built and used with JavaScript. You might see a theme here, it's just JavaScript all the way down. The structure of a MongoDB database is much more flexible as opposed to the more common relational databases.

With the data format of MongoDB also supporting JSON natively - the same format that Digitraffic and most other APIs offer - it works very well for our purposes.

Redis

https://redis.io/

Redis is another database solution we are planning to use. The benefit of Redis over MongoDB is that it supports in-memory storage. This gives massive improvements in looking up data from the database. Each datapoint is also relatively small compared to hardware of today, so we can store quite a bit of data at once.

Redis is used over MongoDB when the user asks for live data and more recent archival data, but older data is transferred to MongoDB.

General technologies

TypeScript

https://typescriptlang.org/

TypeScript is a superset of regular old JavaScript. The code is practically the same, and in a minimal setup can literally be the same as JavaScript code.

The benefits of TypeScript though allow developers to debug their code easier, trust their code, and avoid the more careless bugs, as giving your code types lets your tools tell you when you are doing something wrong.

Docker

https://docker.com/

Docker is used to containerize everything. Frontend is its own container, while each element of the backend gets their own containers.

How containerization helps, is that it avoids the problem of "it works on my machine", meaning if a developer has tested the container locally, it will also work on our servers.

Docker also makes the stack more secure, as Docker allows the administrator to create strict and secure configurations on how accessible each container is to the public. Our backend for example is completely inaccessible to the outside world, but the frontend can still communicate with it.

3.3 Database Architecture

Our database is fairly simple, as it is just one database that holds everything. MongoDB supports objects as it's model, so the following is a paste of the used interface in our code to show the structure.

interface Sensor {
  stationId: number,
  name: string,
  shortName: string,
  timeWindowStart: string,
  timeWindowEnd: string,
  measuredTime: string,
  unit: string,
  value: number
}

interface Station {
  id: number,
  tmsNumber: number,
  dataUpdatedTime: string
  sensorValues: Sensor[]
}

interface StationData {
  id?: ObjectId,
  dataUpdatedTime: string,
  stations: Station[]
}

3.4 Error and Exception Procedures

In unexpected crashes in any of the containers, they will restart themselves. In case of multiple rapid restarts, the containers will stop trying to avoid infinite loops.

CSC Servers handle their errors fairly gracefully and redistribute virtual computing accordingly.

The application right now does not have larger error handling, as we haven't found too many application-breaking states.

4. REJECTED SOLUTIONS AND IDEAS

  • Building the backend with Rust - This was due to one of our developers wanting to learn Rust but was decided against since the learning curve would have been too steep for the tight schedule we were on.
  • Next.js for the frontend - Next.js is a great and developer-friendly React framework, but the customer specifically asked for React.js
  • Tracking specific cars - Too difficult, invasion of privacy, and in the worst case even dangerous

5. IDEAS FOR FURTHER DEVELOPMENT

Features

  • Data Analytics
  • Machine learning
  • More countries
  • Sea traffic

Optimization

Recently there was an early release of million.js, a replacement for the virtual DOM for React. It can offer massive performance boosting for low developer costs.

Original Source http://www.cs.tut.fi/ohj/dokumenttipohjat/pohjat/suunnittelu/hytt_drsuunnittelu.doc

Thank you for the original authors!