# TDIN
###### tags: `TDIN`

## Architectural system design;

The overall project architecture consists of nine microservices of each our group was responsible for five: Users, Subscriptions, Interests, Visualization History, and Recommendations. We also developed a Log Aggregation service as part of the Observability Patterns.

Each of these services are functionally independent, meaning that they do not require the other microservices to be active to function but since the information is distributed, some of their functions can be hindered by it. Moreover, each microservice has its own database, keeping only its relevante information stored.

Since the information is distributed, our microservices require communication between them so to complement it. Apart from the Log service that is only used by every other microserive in order to register every request to our application, the User one is used by the other four so to access user-related information or to validate request authorization. Additionally, the Recommendations service uses both Visualization History and Interests microservices to generate media suggestions based on previous visualizations and interactions. Given that this service could work without the need of a database we decided to add one so to keep track a user's recommendations and to be able to generate these suggestions asynchronously and store them until it is time to display them to the user.


## Services description and their operations;

### Users Service

The Users microservice is a core service used by all others. Just like every other microservice, it has his own database where it will store every registered user in our application which not only provides user-related information to the other microservices, but is also used to validate user requests as for some, specific permissions are required.

Each user has an unique username, a password, and email. Users also have roles, being it basic user or admin where the latter gives special access to some features. Additionally, users have associated access tokens that are required for login verification. Finally, users can be banned from our service, losing most usage features. Bans can only be applied and removed by admins.


### Subscriptions Service

The Subscriptions microservice is a service that manages all the subscriptions this application has available. In its own database, it’s stored all the information necessary to connect to a foreight service, such as netflix or hbo (for example).
Each database entry stores a unique subscription id, the credentials necessary to access the foreight service (username, password and email), as well as the hyperlink to the service. These subscriptions can be either public or private. If private, the field ownerId points to an id of a specific user in the application. If it's a public subscription, the ownerId is assigned the value 0.
A user can create a subscription for himself, making it a private subscription. If the admin creates a subscription, it must have a public scope. Both the users and the admin can only remove its own subscriptions.
Only the admin can view all the subscriptions that exist in this platform.


### Interests Service

The Interests microservice is a service that shows the interest lists of each user. It has its database to store every registered user's interests lists in our application, providing information to the other microservices.

Each database entry stores a unique id, the user id associated with the interests lists, and all the interests lists. A user can create and remove interest lists and add and remove movies/shows from a specific interest list.


### Visualization History Service

The Visualisation microservice is a service that shows the history list of each user. It has its database to store every registered user's history list in our application, providing information to the other microservices.

Each database entry stores a unique id, the user id associated with the history list, and the history list. A user can add and remove movies/shows from their history list.


### Recommendations Service

### Log Service

The Log microservice is used to aggregate logs from all the other services so to keep track of every request made to our application.

A log is composed of a timestamp of the moment of the request, a string to specify in which service this request was made and a string describing what happen on the moment of the request.


## API Gateway design and documentation

### Users Service

| Case | Type | Path | Status | Body | Description |
|:----:|:---:|:----------------:|:------:|:----:|:-------:|
| 1 | GET | api/users | * | | all user's info |
| 2 | GET | api/users/ban | * | | all banned user's and the motives |
| 3 | POST | api/user | * | {uname, passwd, email} | username of the user to create, its password, and email |
| 4 | POST | api/login | * | {uname, passwd} | username and password of the user to login |
| 5 | POST | api/user/ban | * | {uid, motive} | id of user to ban, ban motive |
| 6 | GET | api/user/{id} | * | | get a user's info from their id |
| 7 | GET | api/user/token/{token} | * | | get a user's info from their token |
| 8 | PUT | api/user/{id} | * | {uname, passwd, email} | username of the user to update, its password, and email |
| 9 | PUT | api/promoteuser/{id} | * | | make user damin |
| 10 | PUT | api/demoteuser/{id} | * | | make user admin |
| 11 | GET | api/health | * | | run health check query |

### Subscriptions Service

| Case | Type | Path | Status | Body | Description |
|:----:|:---:|:----------------:|:------:|:----:|:-------:|
| 1 | GET | api/subscriptions | * | - | Gets all subscriptions information |
| 2 | POST | api/{user_id}/subscription/add | * | username, email, password, mediaService, ownerID | Adds a subscripitions to the specified user "user_id" |
| 3 | DELETE | api/{user_id}/subscription/{id}/remove | * | - | Removes the subscription with the id "id" of the user "user_id" |
| 4 | GET | api/health | * | - | Heath check endpoint |

### Interests Service

| Case | Type | Path | Status | Body | Description |
|:----:|:---:|:----------------:|:------:|:----:|:-------:|
| 1 | GET | api/users/interests | * | - | Get all users' interests |
| 2 | GET | api/{userId}/interests | * | - | Get {userId}' interests |
| 3 | PUT | api/{userId}/interests/create | * | interestListName | Create interestListName in {userId} interests list |
| 4 | PUT | api/{userId}/interests/remove | * | interestListName | Remove interestListName in {userId} interests list |
| 5 | GET | api/{userId}/interests/{interestListName} | * | | |
| 6 | PUT | api/{userId}/interests/{interestListName}/add | * | movieName | Add movieName to {interestListName} in {userId} interests list |
| 7 | PUT | api/{userId}/interests/{interestListName}/remove | * | movieName | Remove movieName from {interestListName} in {userId} interests list |
| 8 | GET | api/health | * | | |

### Visualization History Service

| Case | Type | Path | Status | Body | Description |
|:----:|:---:|:----------------:|:------:|:----:|:-------:|
| 1 | GET | api/users/history | * | - | Get all users' histories |
| 2 | GET | api/{userId}/history | * | - | Get {userId}' history |
| 3 | PUT | api/{userId}/history/add | * | movieName | Add movieName to {userId} history |
| 4 | PUT | api/{userId}/history/remove | * | movieName | Remove movieName from {userId} history |
| 5 | GET | api/health | * | | |

### Recommendations Service

| Case | Type | Path | Status | Body | Description |
|:----:|:---:|:----------------:|:------:|:----:|:-------:|
| 1 | GET | api/recomendations | * | - | all calculated recomendations |
| 2 | GET | api/recomendation/{uid} | * | - | the recomendation for user with id = uid|
| 3 | GET | api/health | * | - | run health check query |

### Log Service

| Case | Type | Path | Status | Body | Description |
|:----:|:---:|:----------------:|:------:|:----:|:-------:|
| 1 | GET | api/logs | * | - | Get all service's logs |
| 2 | POST | api/log | * | service, log | Add a log |

## Resilience patterns: specification and implementation;

To implement resilience patterns, our team decided to choose Timeout and Circuit Breaker. We considered that since this is a distributed system and the network will always be unreliable, these two offered the best quality of life to the user.

### Timeout

In order to stop waiting for a response, we count the number of times a timeout was happened to a maximum number of MAX_TO. When that number is met we break connection until a successfull connection can be made.

### Circuit Breaker

After the number of timeouts reaches the allowed maximum, the connection is broken and a new health monitoring process starts to confirm the whether the service is available again for requests or not.

<p>
<img src="https://i.imgur.com/uYiU2av.png" width="350" />
<img src="https://i.imgur.com/RGSxUYN.png" width="350" />
</p>

## Observability patterns: specification and implementation

For observability patterns, the team chose to implement Health Check and Log Aggregation. Health Check is a must have patter since we previously chose Circuit Breaker as a Resilience pattern and Log Aggregation is a great implementation to have so to monitor every request that happens in our application in order to analyze fluxes or catch undetected issues.

### Health Check

For the implementation of the Heal Check pattern we have a GET endpoint with returns 'Healthy' if everything is working accordingly and error if otherwise.


### Log Aggregation

To keep a track of every log that's generated by each service, we have a distributed microservice that handles them as explained previously. Each time a request is made in our application, the handling service sends a request to the Log microservice with the necessary information.


## Security patterns: specification and implementation

Finally, as security patterns, given that we implemented the Users microservice, we decided to choose both Authentication and Authorization patterns.

### Authentication

In order to access some of the features that our application has to offer a user needs to authenticate himself with the a use an username and an email.


### Authorization

In continuation to the previous pattern, some features require some authorization to use, being it an admin role or just being logged in to our service.


## APIs specification (OpenAPI)

### [Users Service](https://app.swaggerhub.com/apis/TDIN-FEUP/UserMS/1.1)
### [Subscriptions Service](https://app.swaggerhub.com/apis/Random66/TDINFLIX/1.0.0-oas3)
### [Interests Service](https://app.swaggerhub.com/apis/DuarteFaria/api-group_2/1.0)
### [Visualization History Service](https://app.swaggerhub.com/apis/DuarteFaria/api-group_2_history/1.0#/)
### [Recommendations Service](https://app.swaggerhub.com/apis/TDIN-FEUP/RecomMS/1.1)
### [Log Service](https://app.swaggerhub.com/apis/Saltitans/TDIN-Log-Aggregation/1.0.0)

### [OpenAPI](https://app.swaggerhub.com/apis/DuarteFaria/api-group_2/1.0)

## Gitlab CI/CD

In order to maintain good code quality and to automatize the deployment process we created some Gitlab jobs: lint, test, build, and deploy. All these jobs run when there's new code added to any of the microservices repositories and they run sequentialy as listed previously.

### Lint

In order to verify errors, bugs, stylistic errors and suspicious constructs in the code, a job is ran with a list of syntax checks against our code, giving an error everytime there's a check is not met. This job runs anytime there's a new push to any branch in one of our repositories.


### Test

Additionally to the linting checks, we also run our code tests so to verify that any new implementations do not break any previous expected behaviours. Just like the previous job, this one runs anytime a new push is made to any one of our repositories


### Build

After checking for linting and testing issues, the deployment process starts. It's necessary to firstly build the application and to do so we created a job for it. This job only runs when there's a push to the master branches of our repositories.


### Deploy

Finally, after all three previous jobs, the deployment starts. Similarly as the previous job, the deployment one only occurs when there's a new commit to the master branch. Here, the job uses the previously set up Heroku API key and Heroku application Gitlab variables to properly deploy our services.


## Service testing

lista de requests

### Subscriptions

#### Heath endpoint

#### Get Subscriptions

#### Add Subscription

#### Remove Subscription

### Visualization History

#### Heath endpoint

#### Get all users history endpoint

#### Get {userId} history endpoint

#### Add {movieName} to {userId} history endpoint

#### Remove {movieName} from {userId} history endpoint

### Interests

#### Heath endpoint

#### Get all users interests lists endpoint

#### Get {userId} interests lists endpoint

#### Create {interestListName} in {userId} interests lists endpoint

#### Remove {interestListName} from {userId} interests lists endpoint

#### Add {movieName} to {interestListName} of {userId} endpoint

#### Remove {movieName} from {interestListName} of {userId} endpoint