Skip to content

Project Phase I

Jump to bottom
Aditya Rudrawar edited this page Feb 8, 2022 · 10 revisions

CoDist

Docker Installation Procedure (Run with Docker)

  • Install Docker and Docker-compose
  • Pull docker images from account: tanukansaldocker123 ( Multiple images created for multiple processor configurations )

  • docker pull tanukansaldocker123/codist-gateway:arm64 || docker pull tanukansaldocker123/codist-gateway:amd64

  • docker pull tanukansaldocker123/codist-registry:arm64 || docker pull tanukansaldocker123/codist-registry:amd64

  • docker pull tanukansaldocker123/codist-plotting:arm64 || docker pull tanukansaldocker123/codist-plotting:amd64

  • docker pull tanukansaldocker123/codist-history:arm64 || docker pull tanukansaldocker123/codist-history:amd64

  • docker pull tanukansaldocker123/codist-postgres:arm64 || docker pull tanukansaldocker123/codist-postgres:amd64

  • docker pull tanukansaldocker123/codist-frontend:arm64 || docker pull tanukansaldocker123/codist-frontend:amd64

  • docker pull mongo:5.0.5-focal

  • Create local folders for Mongo and Postgres volumes, and add to .yml file accordinly.

Run yml file

  • docker-compose -f stackMac.yml up -d || docker-compose -f stackWindows.yml up -d

Project Overview

This project provides an interface to plot historical data provided by NEXRAD AWS based on the user’s input (date, time and radar fields). It makes use of a microservice based architecture to allocate separate functionality to each microservice. As a group with 4 members we have used 4 programming languages and two databases to build this system. The provided functionalities include user registration, logging history, editable inputs and the plotting image.

ITERATION 1

Iteration 1

In the initial days of the first week we decided to go with this architecture, where the microservices

  1. API Gateway in Python using FastAPI.
  2. Registry Microservice NodeJS.
  3. Data Ingestor Microservice Java, Springboot.
  4. Plotting Microservice Python.
  5. MongoDB.

As we were developing and focusing on the architecture, and after discussion with other peers and TA, we realized that Python for API Gateway is not the most appropriate choice as it is not as fast as Java, and not hard coded which can be a requirement if we had to properly scale the system. This and other factors contributed to us switching to Java Spring Boot for API Gateway.

There were other changes as well. It is shown below.

ITERATION 2

Iteration 2

We switched to Java, but now we realized that there is too much communication between microservices and not through a single point. The reason that this might not be a good idea was if we where to scale the system, it would need to group the microservices together to form a group and then the group would need to be replicated horizontally. So we decided that there will be only one single point of Contact between other Microservices and that role was assigned to API Gateway. It would do the heavy loading of routing, checking from registry if the user is authorized to make a specific request or not.

After the requirement change of at least 4 Microservices and 2 database technologies, we decided to ditch the Data Ingestor that was written in Java and include its working to Plotting service, and move the Logging activities from Registry to another Microservice that would be built in GO and connect to PostgreSQL for storing the database. Its ease of use and familiarity to attributed to its selection.

Now there would be an argument as to that a Non Relational Database would be better to store the User history and logs, that was the reason we went with MongoDB in the first place, but now we had to use another Database and most of our features such as Oauth, JWT were already written, so we decided to switch just the User-History to PostgreSQL.

This is the final architecture we went with.

ITERATION 3

Iteration 3

Clone this wiki locally