# Nest.js Fundamentals

## I. HTTP Server Overview & Nest.js Tools:

- Every HTTPS server have the request, response cycle. Here are all the steps that a http server might goes through in its cycle

| Request | Step 1: Validation |Step 2: Auth | Step 3: Routing | Step 4: Business Logic | Step 5: Access Database | Send Response
| -------- | -------- | -------- | -------- | -------- | -------- | -------- |
| User Send Request | Validate data inside the request | Make sure user is authenticated and authorized | Route the request to a particular function | Run some business logic | Access Database | Send back response

- In Nest.js, we have special tools to address each of the step above. Here are the tools for each step

| Step 1: Validation | Step 2: Auth | Step 3: Routing | Step 4: Business Logic | Step 5: Access Database
| -------- | -------- | -------- | -------- | -------- |
| Pipe| Guard| Controller| Service | Repository|

- Here are other tools that are parts of Nest.js

| Part of Nest | It's Functionality |
| -------- | -------- |
|**Controllers (*)**|Handle incoming requests|
|Services|Handle data access and business logics|
|**Modules (*)**|Group code together|
|Pipes|Validate incoming data|
|Filters|Handles errors that occur during request handling|
|Guards|Handle authentication or authorization|
|Interceptors|Adds extra logic to incoming request or outgoing response|
|Repositories|Repositories are used to manage and interact with entities. They provide methods to query the database and perform CRUD operations. In NestJS, repositories are usually created using the @nestjs/typeorm package, which provides a Repository class that includes methods like find, save, update, and delete|
|Entity|Entities are classes that represent the data structure of your application. They define the properties and relationships of the data, and typically map to a database table.|
|DTOs|Data Transfer Object, It describe the different properties that the request body should have|

**Entities vs Repositories**: entities define the shape of your data, while repositories handle the logic for accessing and manipulating that data.

Modules and Controllers are essential in a nest.js application. Other parts can be missed but not these 2

For the diagram down below, **.entity.ts** can be imported in **.module.ts**, **.service.ts** or other files

## II. Nest.js Naming Convention:

- One class per file (there are some exceptions)
- Class names should includes the kind of thing that we are creating
- For example: class AppController, AppModule
- Name of class and name of file should always matchup
- For example. Class name AppController should belong in app.controller.ts
- AppModule should belong in app.module.ts
- Filename template: name.type_of_thing.ts

## III. About HTTP Request and Nest.js Decorators:

- Structure of a http request and Nest.js decorators

| Part Name | Example | Decorators |
| -------- | -------- | -------- |
|Start line|POST /messages/5?validate=true HTTP/1.1|@Param('id') => get number 5. @Query() => get validate=true|
|Headers (1)|Host: localhost:3000|@Headers() point to this part|
|Headers (2)|Content-Type: application/json|@Headers() point to this part|
|Body|{"content": "Hi there"}|@Body() to access this part|

## IV. Services vs Repositories:

| Services | Repositories |
| -------- | -------- |
|It's a class|It's a class|
|Place to put business logic|Place to put storage related logic|
|Uses one or more repositories to find or store data|Usually ends up being a TypeORM entity, a Mongoose schema or similar|

## V. Inversion of Control & Dependencies Injection:

### 1. Inversion of Control Principle:

- Inversion of Control principle:
- In order to write re-usable code, classes should not create instances of its dependencies on its own

- Bad practice. Reasons for being bad practice:
- Whenever there is an instance of the MessageService is created, it creating its own dependency of MessagesRepository
- Therefore, not following Inversion of Control


- Good practice. Reasons for being good practice:
- A new instance of this class doesn't create a new instance of its dependencies
- Instances of MessageService now receives its own dependency
- on the 2nd image, messagesRepo property in this class is referencing to an interface within the same file so it doesn't need to depends on the MessagesRepository

**=> The code is more predictable and encapsulated in 1 file without the need to depends of any other file**



### 2. Dependencies Injection:

**a. What is dependencies injection ?**

Dependency Injection (DI) is a design pattern that enables a class to receive the dependencies it requires from an external source, rather than creating them internally. This allows for easier testing, decoupling, and reusability of code.

**b. Why do we need to use Dependency Injection ?**

- Testability: By using dependency injection, we can easily swap out dependencies with mock objects or stubs during testing, allowing us to isolate and test individual components of our application more easily.

- Modularity: By separating dependencies from the rest of our code, we can create more modular and reusable components that are easier to maintain and extend over time.

- Flexibility: Dependency injection allows us to easily switch between different implementations of a given dependency, without having to modify the code that uses it.

- Decoupling: By separating the creation and management of dependencies from the rest of our code, we can reduce the coupling between different components of our application, making it easier to make changes or refactor our codebase.

## VI. Hashing & Salt:

### 1. Fundamentals of Hashing:

Storing sensitive information like password in plain text is bad. Once the database is exposed, it poses potential threat for accessing of all account within the database. We need to encrypt password to store in the database by hashing

Hashing function takes in your password and return a totally unrelated string of hash. You take that string and store it in your database as your password

When you signin, the API will take the password and run through a hash function. The output will be compared with the hash string you have in the database. This process will authenticate users when they login. Note that if you have the hash string, you can't convert it to the original password. That's one of the rules of hashing.


However, because there is a method of cyber security attack named Rainbow Table attack, we have to make it more complicated and secure in order for the system to be secured.

### 2. Rainbow Table Attack:

The rainbow table attack assume that the hacker somehow got access to the database and made a list of commonly used password. He then generate hash from the list of password that he has and compare it with the password values in the database. This by chances will help him get the email and password of some accounts within the database.

In order to counter this, we have to use something called Salt and setup a system so that it's much harder to the point that it's nearly impossible to conduct this type of attack.

### 3. Final authentication system:

Salt is a randomly generated string. When user sign up, the system combines the password string and the salt string. Then take that combined string to hash it.

The hashed string then combined with the Salt and a separator (can be a dot, slash, etc...) in between will be the value stored in the database


When user signin, the system take the password, combined it with the Salt and hash that combined string. The hash string will be compared with the hash stored in the database, if they're matching, user is authenticated.


This makes it much harder for the Rainbow table attack because hacker has to guess correctly the Salt and password combination at the same time to get access of one account.

## VII. Database Associations:

There are 3 types of associations:
- One To One
- One To Many
- Many To Many

### a. One To One:

- Entity A has a single association with Entity B and Entity B also has a single association with Entity A

### b. One To Many:

- Entity A has associations to multiple instances of Entity B. Instances of Entity B has a single association to an instance of Entity A

### c. Many To Many:

- Entity A has associations to multiple instances of Entity B. Entity B also has associations to multiple instances of Entity A