DEV Community: kim-jos

Express vs Nest

kim-jos — Wed, 10 Nov 2021 11:31:08 +0000

I had the opportunity to create a simple backend program with CRUD operations using ExpressJS though I've been using NestJS. I personally enjoyed using NestJS a lot more than ExpressJS because 1) ExpressJS doesn't provide a structure for your project and 2) NestJS requires less set up.

1) Structure
I like the fact that NestJS provides a set structure for all your projects. If you see NestJS projects you'll notice that almost all their projects are structured very similarly. But ExpressJS provides a lot of freedom for the structure of your projects. I think that there is a best practice but if you see 100 different ExpressJS projects I can guarantee that there will be more variety in project structures when compared NestJS.

I guess that freedom is good for others but bad for people with little experience. Let's get into the details of how it is different. Let's say that there are two different modules: User and Game. Nest structures this by putting all the User related files into a folder called User. That module would have a controller, service, repository, entity, and other testing files. ExpressJS, based on my personal experience, structures their projects according to its function. For example, all the controllers are grouped together and other routers are grouped together, etc.

Nest Controller == Express Router
Nest Service == Express Controller
Nest Repository == Express Repository
Nest Entity == Express Model

1) Set up
Another reason I enjoy using NestJS is because everything is nicely set up for you. When I started my project there were so many errors in ExpressJS and I wasted too much time trying to figure it out. NestJS also provides a great CLI which makes it easy to get started because all the boiler plate code is already created for you.

Although learning dependency injection, inversion of control, and other weird crazy words is difficult in the beginning NestJS really helps users focus on the project at hand instead of the set up which is really convenient for me personally.

Authentication(JWT) & Authorization

kim-jos — Sun, 07 Nov 2021 07:53:09 +0000

This post will go over authentication and authorization. The difference between them is that authentication deals with whether a user is logged in or not and authorization deals with whether that user is authorized to carry out some action. For example, if some actions of creating or deleting information in the database is allowed only for users that are "admin" status this is considered authorization.

The project I was working on implemented authentication using JSON Web Tokens(JWT) and authorization using guards provided by NestJS.

Authentication

I'm going to briefly go over how JWT works because I tried implementing it using the documentation provided online but without a basic understanding it was hard to customize it according to my needs. JWT is basically a token provided by the server side that the user uses to access information. For example, when a user logs in the log in info(email, password) is verified and the server responds with a token that the user uses in the client side to create, read, update, or delete information.

How does NestJS implement authentication?
NestJS uses PassportJS to implement JWT authentication. I'm not going to go over the installation because it is well documented. If you follow the NestJS's documentation to implement JWT authentication you will probably have to create a bunch of files and I intend to go over how those files interact with each other because I think that was what really confused me in the beginning. The relevant files are: 1) auth.service, 2) jwt-auth.guard, and 3) jwt.strategy

The two big steps in implementing authentication are 1) signing in by receiving a JWT from the server and 2) using guards to prevent access to unauthenticated users.

Step 1: Signing in

To begin, the order in which the files are executed is 1) auth.service, 2) jwt.strategy, then 3) jwt-auth.guard.

API call to localhost:3000/auth/login

@Controller('auth')
export class AuthController {
  constructor(private authService: AuthService) { }

  @Post('login')
  async login(@Request() req) {
    return this.authService.login(req); // this is the method that we're going over
  }
}

The "login" method in the service looks like this:

@Injectable()
export class AuthService {
  constructor(
    private usersService: UsersService,
    private jwtService: JwtService
  ) { }

  async validateUser(email: string, pass: string): Promise<any> {
    const user = await this.usersService.findByEmail(email);

    if (user && await bcrypt.compare(pass, user.password)) {
      const { password, ...result } = user;
      return result;
    }
    return null;
  }

  async login(req: any) { // LOOK HERE!
    console.log('authService', req.body)
    const { email, password } = req.body
    const user = await this.usersService.findByEmail(email)
    const { role, id } = user;

    const validatedUser = await this.validateUser(email, password);
    if (!validatedUser) throw new UnauthorizedException('Unauthorized user');

    const payload = { email, password, role, id };
    const accessToken = this.jwtService.sign(payload) // this part signs the user in!! "sign" is a method provided by JWT
    return { accessToken };
  }
}

By this part we're signed in!!

Step 2: Using guards to prevent access to unauthenticated users

Only people with this JWT token will be able to do CRUD operations in other parts of the app. In this example, only logged in users will be able to create, delete, etc. a "menu".

In NestJS you can use a "guard" to prevent unauthenticated users from accessing routes. If you don't have a JWT in the header of your HTTP request you will be denied access.

@UseGuards(JwtAuthGuard, RolesGuard) //this is the JWT Auth Guard
@Controller('menus')
export class MenusController {
  constructor(private readonly menusService: MenusService) { }

  @Roles(Role.Admin)
  @Post()
  create(@Body() createMenuDto: CreateMenuDto) {
    return this.menusService.create(createMenuDto);
  }
}

Now, this is the hard part. How does this "JwtAuthGuard" work?
Im going to break it down into 3 mains steps.
1) In your auth.service file you sign a payload which gives you an access token. 2) The information in the payload that you signed is sent to the jwt.strategy file where it is validated and you can choose to send back information of your choice(I think that there is a jwt best practice here but I am currently unaware of it). 3) The information you return in the jwt.strategy file then goes to the jwt-auth.guard file where it is returned in the "handleRequest" method as the second argument named "user". If there is no user then the guard throws an error, preventing the user from accessing the route.

Authorization

The project that I was working on had 2 types of users: a normal user and an admin user. The admin user is the only type of user that can do CRUD operations while a normal user can only "get" information.

Now there are 3 main files that work together to implement an authorization guard: 1) roles.guard, 2) roles.decorator, and 3) roles.types. The titles are self-explanatory, there is a roles guard and a decorator and a files to take care of the types of roles there are.

Let's take a look at the menu.controller again.

@UseGuards(JwtAuthGuard, RolesGuard) // RolesGuard goes here!!
@Controller('menus')
export class MenusController {
  constructor(private readonly menusService: MenusService) { }

  @Roles(Role.Admin)  // ONLY admins can access this route
  @Post()
  create(@Body() createMenuDto: CreateMenuDto) {
    return this.menusService.create(createMenuDto);
  }
}

You will be able to see that the "create" method is protected by a "Roles(Role.Admin)" decorator. The "Role.Admin" part is passed into the roles.guard file as a reflector. The biggest problem I faced was that I had trouble getting the user information in the HTTP request. The reason I had to get the user information form the HTTP request was because NestJS guards cannot use dependency injection which means that you cannot use the user service. This is how it connects with JWT. So, I decided to return the role information in the jwt.strategy file. The jwt.strategy file runs before the guard so the user info is inserted into the request. How I figured this out was that there was a user object in the HTTP request in the roles.guard but not in the auth.controller. So, I realized that it was being inserted somewhere and I realized that it was in the jwt.strategy file. The roles.guard looks like the code below.

@Injectable()
export class RolesGuard implements CanActivate {
  constructor(private reflector: Reflector) { } //to get the info from custom decorator(@Roles())

  canActivate(context: ExecutionContext) {

    const requiredRoles = this.reflector.getAllAndOverride<Role[]>(ROLES_KEY, [
      context.getHandler(),
      context.getClass()
    ])
    console.log('rolesGuard', requiredRoles)
    if (!requiredRoles) return true;

    const { user } = context.switchToHttp().getRequest();
    console.log('rolesGuard', user)
    return requiredRoles.some((role) => user.role?.includes(role));
  }
}

I know that I will probably work with authentication in the future and I think this article a good reminder for myself to understand how it all works. I hope it helps anyone else reading.

For anyone interested this is a link to the project I created.

Deploying to AWS EC2

kim-jos — Wed, 03 Nov 2021 09:44:53 +0000

My team was building a project where users can write posts and comments (link). This project is mostly comprised of CRUD operations and used MongoDB. This post will be going over how I deployed this project using AWS EC2.

My experience with deploying an app in the past was mostly just firebase. Google makes it pretty easy for users to deploy their apps but this time I tried to use AWS because I really wanted to know why it was so widely used. The process was actually very different from firebase.

The first problem was that AWS provides so many services for deploying an app which makes it difficult to know which one is the right service for me. But in the end I chose EC2 because it's the service used by companies and I wanted to get some exposure to it.

I think the biggest difference between deploying with EC2 and firebase was that AWS actually provided me with a server (online computer). You have to actually choose an operating system. I went with the Linux operating system provided by Amazon because it was free. I think Ubuntu is another popular option. This whole process is called creating an "instance".

While you are creating an instance, it depends on what you are doing but if you are deploying a mini app you just have to set the security settings so that the ports that you use are open. Once you are done with that you are ready to launch your instance.

Your instance was launched, now you have to deploy your app on it. Because my app was built using Node.js I downloaded Node.js and git so that I can download my project using git commands. Once you download your app, you run it using "npm run start:prod" for Node apps. Then you are set to go! If you access the URL provided by AWS then you will see that your app is running live. But the problem is that once you shut your app down, the app stops running. To fix this problem you have to use a program that keeps it running at all times. There are multiple libraries that you can use to implement this such as "forever", "pm2", and etc. I used "pm2" because it was more widely used.

What Problems of Bitcoin Does Ethereum Solve?

kim-jos — Sat, 16 Oct 2021 05:35:39 +0000

Ethereum was created by Vitalik and his team as an attempt to improve the features of Bitcoin. This post will discuss the problems that Ethereum solves (this post will not cover PoW and PoS).

The main difference between Bitcoin and Ethereum is Ethereum's ability to store code that executes programs. This means that it gives any application built on the blockchain the ability to become decentralized. No super server would be necessary to store all our data but we would instead use everyone's computer to execute apps and programs.

How does Ethereum make this possible?
Ethereum uses a feature called a smart contracts. It allows anyone to code on the blockchain. Bitcoin also has this feature but its major downfall is that it isn't Turing Complete, meaning that you cannot implement certain types of logic. The main reason Bitcoin Script is not Turing Complete is because it cannot implement loops (e.g. for loop, while loop, etc.). The reason loops were not created in Bitcoin Script was because it could slow down the process tremendously because loops can run forever especially if some malicious user had the motive to do so.

However, Vitalik, the creator of Ethereum, decided that it was necessary for the language to be Turing Complete and went on to create Ethereum and Solidity.

Problem 1: What if someone creates a virus in the network?
If a malicious user creates a virus then everyone will have a virus copied on to their network. Ethereum implements something called the Ethereum Virtual Machine(EVM). Whenever someone decides to participate in the Ethereum network you actually participate as an EVM. This basically means that there is another computer(virtual machine) running inside your computer and code that gets executed in the virtual machine runs there only. So any virus that attempts to access your camera or files on your hard drive would be prevented from doing so.

Problem 2: What if someone creates an infinite loop that slows down the network?
Ethereum implements something called Gas. Gases are a price to every operation that is run on the network. This incentivizes everyone to write really good, efficient code because the more operations you have the more expensive it is to run. Now people may ask whether Ether and Gas are two different things. Yes, they are. The reason Ether is not used as a payment method for smart contracts is because the value of Ether fluctuates a lot. But there is a conversion rate for Gas into Ether which is decided by community consensus.

What is a Blockchain?

kim-jos — Mon, 11 Oct 2021 03:52:01 +0000

What is blockchain?
According to Wikipedia, it is a list of records, or blocks, that are linked together using cryptography.

On a very basic level, a block consists of four main things:

data - any data that you want to store
previous hash - this connects the block to its previous block
hash - code that identifies the block
nonce - arbitrary random number

There are five important concepts of blockchains:

Encryption(SHA256)
Immutable ledger
Distributed p2p ledger
Mining
Consensus protocol

Encryption(SHA256)
This is the code that you can identify any block with. Imagine it as the fingerprint of the block. SHA256 is the encryption tool that creates this fingerprint for each block. SHA stands for secure hashed algorithm and the 256 stands for the number of bits the algorithm has which is 64 characters in length.

Five important characteristics of SHA256 are as follows:

Deterministic - the same input outputs the same hash each time
Avalanche Effect - a minor change in the input outputs a completely different hash
One-way - you cannot reverse engineer the hash meaning you cannot determine the input using the output
Fast computation
Withstands collisions - different inputs cannot have the same output

Immutable ledger
Let's first define the two words. Immutable means unchangeable. A ledger is basically a list of all business transactions. For example, if you went to a nearby store and paid for a coke with your debit card then that transaction is stored in your bank ledger. Why is this ledger important? It's important because that's the way we can keep track of how much money you have left in your account. If you claim that you never bought anything in the store the ledger is the evidence used to prove that your claim is false.

How is this relevant to blockchain?
It's relevant because blockchains can serve as this ledger that's immutable. For example, if you wanted to buy a house then you would pay for it and then register yourself as the owner of the home in some government institution. That way no one can arbitrarily claim that your home is theirs because the government institution serves as the ledger in this case. But with blockchain we are ridding this government institution and replacing it with blockchain. There are many benefits to this because no one can tamper with the data. If someone tries to change the data in the blockchain then it would change the hash of the blockchain which would invalidate the blockchain with the tampered data.

Distributed p2p ledger
Like before, let's define the words first. Distributed just means spread out and p2p which stands for peer-to-peer means links between peers.

How is this relevant to blockchain?
Basically the blockchain is stored not in one central place but distributed among all computers on the network. In other words, all the computers on the network have a copy of the blockchain. Whenever a new transaction is made on a certain computer the transaction is signaled to all the other computers on the network where they make a copy of the newly added blockchain.

Why is this necessary?
This p2p networking makes it extremely difficult for anyone to tamper with blockchain. When someone tries to tamper with a blockchain by, for example, trying to change the name of the owner of a house all the other computers on the network will realize that it was getting tampered with because the majority of the computers on the network have a different copy of blockchain. This prevents the new tampered block from being attached to the chain of blocks. We will go into more detail regarding this issue in the consensus protocol part below.

Mining
Let's review once again what a blockchain is composed of:

data - any data that you want to store
previous hash - this connects the block to its previous block
hash - code that identifies block
nonce
blockchain number

The hash of a blockchain is generated as a combination of the blockchain number, previous hash, data, and nonce. The miners basically mine blockchains by finding the nonce that generates the hash. Only the nonce is computed by the miners because it wouldn't make sense to change anything else. For example, you can't change the data because that would be tampering with the data and you can't change the previous hash because that would break the connection with the previous blockchain. So, the way these blockchains are mined is by someone or something finding the number that goes in the nonce. Miners use brute force to guess the nonce of the blockchain. Whoever guesses the nonce first gets a financial reward in the form of coins in the case of Bitcoin.

Consensus protocol
Consensus means majority opinion and protocol simply means some rule. The reason we need this consensus protocol is because the blockchain uses a p2p network like we discussed above. An important concept that is frequently mentioned is the Byzantine General's Problem. It deals with the problem of who to believe which is very important in blockchain because it is also composed of a network of computers.

What is the Byzantine General's Problem?
Assume there are 5 Byzantine generals and one of them is a traitor. They need to either attack an enemy base or retreat. Now the generals need to be able to distinguish whether a signal is coming from a fellow general or a traitor. The way they do this is by tallying the number of signals they receive from each other and, of course, majority rules. So, if there are 5 people you will receive 4 signals in total (excluding your signal). If there is one traitor then you would receive 3 signals of the same kind which is majority. Now this would not work if more than 30% of the generals are traitors.

How is this relevant to blockchain?
This is relevant to blockchain in the sense that all the computers on the blockchain network are like the generals. They need to be able to tell whether the signals they receive from the other computers are valid or not and they do this by the number of signals they get.

Now how do we actually implement this in real life?
There are two main consensus protocols: Proof-of-Work("PoW") and Proof-of-Stake("PoS"). These consensus protocols allow other computers to distinguish whether a signal is valid or not.

This post will discuss PoW because Bitcoin implements PoW and will provide a good foundation on how other consensus protocols work.

We have already briefly discussed how PoW works in the blockchain mining section. The miners need to brute force their way to find the nonce that generates the hash of the blockchain and once they do they are rewarded financially with a coin. This is PoW.

One main problem is that two different blocks can be added to the chain. Say about 70% of the computers on the network have block "A" and the rest have block "B". What happens then? The network waits for another block to be added to the chain. The longer chain usually wins. What this means is that the longer chain is copied over to the other computers that had block "B" and block "B" is removed from the chain. Whichever side has more computing power has a higher probability of finding the next nonce that generates the hash which is why this is called PoW. The computers that have 51% of the computing power usually wins majority.

OOP Basics

kim-jos — Mon, 27 Sep 2021 10:17:57 +0000

I'm going to go over object-oriented-programming("OOP") so that I can review it whenever I need to.

What was the problem before OOP?
First, let's go over what kind of problem it solved. Before, OOP the dominant programming paradigm was procedural programming. Procedural programming was simply just a lot of data stored in variables and a functions that performed some code on those variables. The problem was that as this type of code scaled the same lines of code were being used repeatedly throughout the project (aka spaghetti code).

How did OOP solve this problem?
Encapsulation
What OOP did was simply organize related variables and functions together into objects. The variables become known as properties and the functions became known as methods.

//Procedural programming
let firstName = 'Joseph';
let lastName = 'Kim';

function findFullName(firstName, lastName) {
  return firstName + lastName;
}

//OOP
let user = {
  firstName: 'Joseph',
  lastName: 'Kim'
  findFullName() {
    return this.firstName + this.lastName
  }
}
user.findFullName();

As we can see in the example above, in procedural programming the variables and functions are decoupled while in OOP they are organized into one object. In what way is this better? There are less parameters in the OOP style. With fewer parameters it is easier to maintain the function and considered better practice in the coding world.

Abstraction
Abstraction just means it hides the complexities away from you so that you don't have to deal with it. For example, think of a microwave. You just have to click start for the microwave to start. You do not have to spend time trying to understand how the microwave works internally in order to use it. This concept is basically the same in programming (e.g. you don't have to know how libraries work internally to use the methods that it provides).

What benefit does this have?
1)Objects can have many properties and methods but some of them can be hidden from the outside making it simpler to work with. 2)Another benefit is that it reduces the impact when changes are made. If methods or properties are hidden or kept private then when a problem occurs we know that those properties or methods are not part of the problem that occurred.

Inheritance
Inheritance is when you inherit some properties or methods from another object or class. This helps because you don't have to write the same method or property each time you need it in different objects. You can just make it once and reuse it.

Polymorphism
This is a really weird word but it simply means many(poly) + forms(morphism). So how is this relevant to programming? Long story short, it helps us not use endless amounts of if/else statements. How is this possible? Let's use an example. There are three classes: Animal, Pig, and Dog. Dog and Cat are child objects of Animal which means it can access Animal's properties and methods.

//Dog extends Animal
//Pig extends Animal

let kingdom: Animal[] = new Animal[];
let doggy = new Dog();
let piggy = new Pig();
kingdom.push(doggy, piggy);

for (let animal of kingdom) {
  animal.eat(); 
  animal.sleep();
  //we don't need to use if dog then sleep or if pig then sleep
  //we can just use eat() or sleep() because they are child object of Animal;
}

Unit Testing with Jasmine

kim-jos — Thu, 23 Sep 2021 15:08:55 +0000

Why do we need test code?

I recently created some test code for an Angular project. It was my first time learning how to test but I realized how important it was because of how much our team can be put at ease knowing that all important tests pass. We can be put at ease because we know our project will work according to how we want it even if we add new features to our project. This is my personal opinion but I think that if your project is not changing and will stay the same forever there is no need to add test code to your project. It is most useful when your project is constantly evolving or improving in some way.

Angular provides Jasmine, a testing framework, out of the box which is why our team used it. But, I believe, the overarching concepts among all different testing frameworks are similar; so, getting one down would help you easily transition into different testing frameworks. Now, let's get into what these overarching concepts are and how I implemented them in my project.

What is testing exactly?

I think everyone can intuitively somewhat guess what testing is. Basically, testing is checking(or testing) to see if our code works the way we want it to in different situations. Now the hard part is actually implementing these concepts which I will go over below.

There are different types of testing: unit, integration, and e2e(end-to-end). This post will go over unit testing because it is the most commonly used and a great starting point. Now, what is unit testing? Unit testing is basically testing only the unit and excluding all dependency injections("DIs"), child components, and all other related things. This helps pinpoint the problem when there is one. For example, if there are two components called parentComponent and childComponent and you are testing parentComponent, then you would exclude childComponent from the test. How do you do that? That's the hard part.

How do you do unit testing?

A component is usually pretty useless without its DIs, child components, and etc. So it was hard for me to wrap around how you can test a component without its dependencies. But basically, you have to make fake DIs, child components, and etc. For example, if your actual project has a service to asynchronously get some data from somewhere you would have to create a fake service or as called in Jasmine a "spy" to replace that service that the component depends on.

I won't go over everything that I did in the project because I don't think it'll be too useful for everyone but I do think there are three main difficulties I faced that everyone will to some degree face as well when writing test code.

What are the three main difficulties?

Learning how to deal with asynchronous functions
Learning how to make fakes(or stubs) for components, DIs, and etc.
Understanding the whole process of testing

Understanding the whole process of testing

Let's go over the easiest one of the three, understanding the whole process of testing including just getting used to the new syntax. There are methods like "describe", "beforeEach", "it", "expect", etc. which are methods provided in Jasmine. Let's go over those four methods because it will give the general idea of how test code works.

"describe" method("suite"): this is basically where you put in all your test code and is used to group related specs
"it" method("spec"): this is a spec within the suite
"beforeEach" method: this runs before each spec method
"expect" method: you expect the specs to have a certain value or do something

I'm sure this makes no sense at all. Let's go over an example. Let's say that when a search function is called we want a spinner show method to have been called. This situation in test code would look like the example below.

let component: ParentComponent;

describe("parentComponent", () => { //this is the suite
 beforeEach(() => {
    component = fixture.componentInstance;
 });
 it('should show the spinner when the component is loading', () => { 
  component.search(); // run the search function in the component
  expect(component.spinner.show).toHaveBeenCalled(); 
//You expect the "show" method in the spinner to have been called after running the search function in the component
 })
}

It really depends on how you implemented your spinner in your project, but in mine the spinner has a show method that is called when the component search function is called.

Learning how to make fakes(or stubs)

Fakes are also called stubs, spies, mocks, and etc. I think there are some differences but I will be using them interchangeably for convenience purposes.

In testing, you basically have to make stubs for everything. If a component has a child component, a dependency injection, or anything else that's no within the component we're testing then just think that a stub needs to be made.

But, I do think this part, making stubs, is where the architecture of Angular really shines. Unlike Vue or React, Angular is composed of modules and uses dependency injections to separate the view (component) from the data processing(services) functionality . It is really easy to know which dependencies you need for each component making it easier to know which stubs you need to create.

In this post I will go over how you can create stubs 1)for services or dependency injections and 2)for values that should be return as a result of calling a method.

describe('IssuesComponent', () => {
  let component: IssuesComponent;
  let fixture: ComponentFixture<IssuesComponent>;

  beforeEach( waitForAsync(() => {
    await TestBed.configureTestingModule({
      declarations: [ ParentComponent ],
      schemas:[NO_ERRORS_SCHEMA],
      providers:[
        {provide: DataService, useValue:jasmine.createSpyObj<DataService>("DataService", ['search'])},
      ] // 1)this is how you create a spy for a service. you are basically telling Jasmine to use this spy instead of the actual dataservice.
    })
    .compileComponents();
  }));

  beforeEach( waitForAsync(() => {
    fixture = TestBed.createComponent(IssuesComponent);
    component = fixture.componentInstance;
  }));

  it('should run the search function properly', fakeAsync (() => {
    (<any>component).issue.search.and.returnValue(of({
      hits:{hits:[], total:{value:3, relation: 'eq'}},
      timeTookForSearch:3,
      aggregations:{status:{buckets:[]}}
    }).pipe(delay(10)) // add delay to make the observable async
    ) // 2)this part is creating a fake response
// everytime the search function is called it returns the fake value that you tell it to return

I didn't go over how to make stubs for components and many other things but I do think this is a good start.

Learning how to deal with asynchronous functions

We all know that some functions are asynchronous which means that we have to deal with this problem while testing as well. Every time everything seems to be working logically but does not work, the problem, usually, lied in some asynchronous function for me. Jasmine provides tools to test asynchronous functions. The methods are called "fakeAsync" and "tick". "fakeAsync" creates a zone in which we can pass time manually using "tick".

describe("parentComponent", () => {
 it('should test async functions', fakeAsync( () => { 
  let test = false;
  setTimeout(() => {
    test = true;
    expect(test).toBeTruthy();
  }, 1000); // you set the timeout to be 1000ms

  tick(1000); // tick fast forwards time by 1000ms in this example
 }))
})

There's also another method you can use called "flushMicrotasks()" instead of "tick()". You have to understand the callback queue and microtask queue to understand how this works. Check this post to understand how microtask queues work
Basically, tick and flushMicrotasks is the same thing but flushMicrotasks you flush the microtask queue while tick flushes the callback queue.

Backend Basics - Database

kim-jos — Wed, 15 Sep 2021 10:19:24 +0000

Another important part of the backend is the database. I will go over how the databases are structured and go over what libraries and tools Nestjs provides to work with a database. This post will go over SQL databases. Let's first begin by thinking of SQL databases as tables like those used in Microsoft Excel or Google Sheets.

There are three key words that we need to understand before we move on.

Entity(table): basically, the name of the table
Attribute(column): the titles of the columns in the table
Relation(primary key, foreign key): this exlains the relationship between different tables. This is problably the hardest part to grasp when working with SQL databases.

The above will hopefully make more sense with the examples I provide below.

What are entities and attributes?

Let's imagine a web page that has a post that was written by a user and a comment written by another user. In this case we have three different "entities": the author, the post, and the comment. All these entities have different attributes. For example, the post entity might have attributes such as the text of the post, the time it was written, and the title of the post. Once all those attributes are determined, the entity is converted into a table.

What are the relations among the entities?

The relations between the three entities we mentioned above are that the user writes posts and comments, and every comment is associated with a post (this is because comments cannot standalone like posts, they have to be a comment on some post). The diagram below provides a visual representation of the relations between the different entities.

Can you connect the diagram above with the tables below?

To see the relations between the tables you can do something like this:

You can join the tables together. As you can see, I highlighted the primary key in red and the foreign key in green. Primary keys are IDs that are unique, meaning that it can never be the same for any row. For example, for the user, if you use the name as the primary key there may be some people with the same name so you'll have a problem there. But, the userId is unique to that user which is why it was chosen as the primary key for that entity. Foreign keys are basically the the keys that refer to another table. The Post table has a foreign key of UserId. This means that the IDs in that column refer to the UserId in the User table.

Now that we have a gist of the relations between tables let's dive a little deeper with concepts called cardinality and optionality.

What is cardinality?

There are three types of cardinality relationships: one-to-one, one-to-many, and many-to-many which can be see in the ERD diagram I created below.

Using the example above,
1) Let's go over the relation between the user and the comment. One user can write numerous comments but each comment can be written by one user. So this is a one-to-many relation (one user, many comments).

2) The user and post relation is a many-to-many relation. Of course, this may differ according to how you're creating your app but in this case, the user can write numerous posts and any one post can have several users. Imagining a wikipedia page will probably help (many users, many comments).

3) Hopefully, you can now guess what a one-to-one relationship is.

What is optionality?

Optionality, as the name suggests, is a way to show if the relation is optional or not. As you can see in the diagram below, the O signifies that the relation is optional while the straight line signifies that it is mandatory.

Going back to our example, let's see the relation between the user and comment in terms of optionality. The comment is optional to the user which means that the user is not required to write a comment. However, if a comment exists then it is mandatory for it to have a user who wrote it because comments can't write themselves.

Now that we have a general understanding of SQL databases, let's see how Nestjs implements these concepts.

In my other post, I go over five main functions of the server which are the following:

Pipe - validation
Guard - authentication
Controller - routing
Service - business logic
Repository - accessing a database.

I covered all of them in the other post except the repository function which I will cover now.

What is the repository function?

The repository is the class that communicates directly with the database. Fortunately, unlike the other functions where we have to create the classes ourselves, the repository class is created by an external library that we will be using called TypeORM. All the methods in TypeORM can be summarized into CRUD(create, read, update, and delete) functions.

Although we don't have to worry about creating a separate repository because TypeORM does that for us, we still need to create an entity that TypeORM will use to create a table that will be stored in the database.

import { OneToMany, Entity, Column, PrimaryGeneratedColumn } from "typeorm";

@Entity()
export class User {
    @PrimaryGeneratedColumn() //primary key (this is generated automatically by TypeORM)
    id: number;

    @Column()
    name: string;

    @Column()
    intro: string;

    @Column()
    dateRegistered: Date;

    //@OneToMany()
    //TypeORM provides one-to-many, one-to-one, many-to-many, etc. decorators
}

Can you make the connection between this entity in Nestjs with the entity diagram I drew above? This entity will be created in to a table and saved into an SQL database. There are a couple extra steps you need to take with the modules in order to help Nestjs recognize the entities but I will not get into that here.

Now that an entity is created, let's see how we can actually use the repository functions that TypeORM made for us within our project.

import { Injectable } from "@nestjs/common";
import { Repository } from "typeorm";
import { InjectRepository } from "@nestjs/typeorm";
import { User } from "./user.entity"; //the folder name is just a random one I made up

export class UserService {
  constructor(@InjectRespository(User) private userRepository: Repository<User>) {}

  createUser(name:string, intro: string) {
    const user = this.userRepository.create({name, intro});
    return this.userRepository.save(user);
  }
}

Notice that you have to use DI to inject the repository into the service that we're going to use. The "create" and "save" methods used in the example above are methods provided by TypeORM. Just think of them as functions in the repository class that TypeORM automatically generated for us. If you check the TypeORM website you can find all the methods that you can use to CRUD your data in the database.

Backend Basics - Server

kim-jos — Sun, 12 Sep 2021 11:46:41 +0000

I mostly used Firebase for my backend for my projects because it provided a lot of tools that made it easy to create a backend. Recently, though, I've been gaining some interest in backend development and decided to look into servers and databases. The backend framework I decided to use is Nestjs. To give a brief introduction to Nestjs, it's a framework that was inspired by Angular so it is very similar syntactically which is a big reason why I chose it and it also uses Expressjs under the hood. It also provides a lot of structure for my projects in comparison to Express which made it easy for a beginner like myself.

From what I have gathered online, backend development, on the very basic level, is composed of the server and the database. This post will go over what a server does and how Nestjs works as a server.

What does a Server do?

When the browser sends an HTTP request, the server sends back an appropriate response. But before responding it does the following:

Validation: validates the data from the response
Authentication: verifies the user's credentials
Routing: routes the request to the relevant function
Business logic: the function mentioned in routing
Access a database

Nestjs provides the following features for each function mentioned above:

Pipe - validation
Guard - authentication
Controller - routing
Service - business logic
Repository - accessing a database

Controllers

How does a controller work?

When a user interacts with the frontend it makes requests to the backend to do something for them. The main request types are GET, POST, PUT, and DELETE which follows the REST architectural style. These methods basically tell the backend to either create, read (get), update, or delete data.

How does Nestjs's controller work?

Nestjs provides GET, PUT, POST, DELETE, and etc. decorators to route the requests. The following is an example of how a controller would look like in Nestjs.

import { Controller, Get, Post } from "@nestjs/common"

@Controller('/messages')
export class UserController {
  // GET
  // /messages
  @Get()  // the "Get" decorator
  getMessages() // the function that gets executed

  // GET
  // /messages/:id
  @Get('/:id')
  getSingleMessage()

  // POST
  // /messages
  @Post()
  updateMessage()

}

When the request matches the request type (Get, Post, etc.) and the route (e.g. "/messages") then Nestjs executes the function below the decorator.

How do you extract information from the request?

Let's begin with an example of why we would need to extract information. When a browser POSTs some info, the server needs to get a hold of the body of the data in order to store it or to run some business logic on it. We can get a hold of not only the data but also the parameter and queries.

What does a request (HTTP request) look like?
A request consists of the following:

Start line: request type and route
Header: Content-type, host, etc.
Body: data

Start line: POST /users/5?validate=true // Start line

HOST: localhost:4200  // Header
Content-Type: application/json // Header

Body: {"content": "hi!"} // Body

How does Nestjs allow you to access the data in a HTTP request?
Nestjs provides decorators to access the data you need.

@Param('id') // this would get you the "5" in the route below
@Query() // this would get you the "validate=true" in the route below
Start line: POST /users/5?validate=true 

@Headers()
HOST: localhost:4200
Content-Type: application/json

@Body()
Body: {"content": "hi!"}

Let's use the decorators in the example we used above.

import { Controller, Get, Post, Body } from "@nestjs/common"

@Controller('/messages')
export class MessagesController {
  // GET
  // /messages
  @Get()  
  getMessages() 

  // GET
  // /messages/:id
  @Get('/:id')
  getSingleMessage(@Param('id') id: string) {
    console.log(id) // this would print the id in the request
  }

  // POST
  // /messages
  // {"content": "im a user"}
  @Post() // use the body decorator here to access the data in the HTTP request
  updateUser(@Body() body: any) {
    console.log(body) // this would print the body in the request
  }

}

Pipes

How does a pipe work?

The pipe runs before the request gets to the controller to validate the data. For example, if a POST request has a body that contains a number but the controller can only accept a string. Then the pipe would reject it before it gets to the controller.

Nestjs provides a built-in ValidationPipe that has many commonly used validations. To use the pipe, you just have to create a class the describes the different properties that a request body should have.

Pipe classes are usually called a Data Transfer Objects("Dto").

Let's see how you would use this in the example above.

import { IsString } from 'class-validator'

export class MessageDto {
  @IsString()
  content: string;
}

import { Controller, Get, Post, Body } from "@nestjs/common"
import { MessageDto } from './messageDto'

@Controller('/messages')
export class MessagesController {
  // GET
  // /messages
  @Get()  
  getMessages() 

  // GET
  // /messages/:id
  @Get('/:id')
  getSingleMessage(@Param('id') id: string) {
    console.log(id) 
  }

  // POST
  // /messages
  // {"content": "im a user"}
  @Post()
  updateUser(@Body() body: MessageDto) { 
// we replaced the type with the MessageDto. That's all we need to do to use the pipe
    console.log(body)
  }

}

Repository

The repository is a class used to interact with the database. This part goes into TypeORM which is explained in this post.

Service

Services are where all of the business logic is located. It also uses the methods in the repository class to interact with the database. Many methods in the service are similar to the methods in the repository and may appear redundant but this structure of separating the business logic from the interaction with the database offers benefits of writing easier test code, finding bugs, and etc.


export class MessageService {

  async findOne(id: string) {
    return this.messageRepository.findOne(id);
  }

  async findAll() {
    return this.messageRepository.findAll();
  }

  async create(content: string) {
    return this.messageRepository.create(content);
  }
}

Now we have to go over how Nestjs combines all these features together to maintain a project. One of the most important concepts is dependency injection. In simple terms, each class depends on some other class and needs to get that class that it depends on injected into it. I go into further detail below.

Inversion of Control ("IoC")

I'm going over IoC before dependency injection because this is the principle that the dependency injection design pattern is trying to implement.

The IoC basically states that classes should not create instances of its dependencies on its own. Instead, they should get their dependencies from an outside source. This would help classes become more reusable as projects scale.

In Nest, there is a Nest IoC Container that does this job for us which is further explained below.


export class MessageController {
  constructor(private messageService = new MessageService()) {} // this would be a violation of the IoC principle because an instance is created manually

  constructor(private messageService: MessageService) {} //this method is encouraged. You would have to import it and include it in the appropriate module provider to allow the Nest IoC Container know that it's a dependency injection.
}

Dependency Injection ("DI")

Nestjs revolves around DI. So I think it'd be helpful to understand how Nestjs uses it.

First, let's go over how our different classes depend on each other in our example.

MessageController --> MessageService --> MessageRepository

As seen in the diagram above, the messageController class depends on the messageService class and the messageService class depends on the messageRepository class to work properly.

The Nest IoC Container records all these classes and their dependencies. After it is done recording, it creates instances of all the required dependencies and ultimately returns the controller instance. The important benefit of using this container is that Nest reuses the instances that it created. So, if a project grows and there are multiple controllers that need a certain service, Nest would use the already created instance of the service instead of creating another one.

Creating a Simple Notice Board Using Angular

kim-jos — Tue, 27 Jul 2021 12:14:39 +0000

What I'm building

I'm creating a simple notice board app using Angular to solidify my understanding of it.

The project will have a dashboard listing all the notices with the ability to edit, delete and add notices. Each notice will have linked page that displays the details of the notice and comments that other users can add to the notice. This stuff is pretty basic with the only the comment section being a little tricky. I decided to simply add another collection to a document in firebase to implement the comment feature. I'm using firebase for my backend because it provides a lot of APIs which make my life easier.

Features I'm trying out for the first time

To make this project a little more interesting for myself I've decided to add some additional features to that I've never tried.

Infinite scrolling

I'm only allowing the page to show three notices initially and if the user scrolls down it will add another three notices to the list and so on and so forth. This is pretty easily implemented using firebase although it did take me some time to understand the logic behind how something like infinite scrolling can be implemented.

It was difficult to understand at first because I didn't realize that the collections in firebase could be ordered. But I realized that you can order them according to time or any other property you created in the database. Firebase has a pretty simple method where you can limit the number of items.

Also, there is one thing I'm proud of. I implemented DRY(don't repeat yourself). I was also originally planning to make 2 different functions. One to get the data to load when the component was first mounted and another one to get 3 notices thereafter if the user scrolling down. But, for some reason, I felt like that wasn't necessary. After some research, I realized that if you use "?" in the parameter, the function doesn't need to always take in an argument and does not throw an error. Very simple but very satisfying for me at this stage of my coding journey.

getNoticeList(row?: Date) { // "?" saved me from writing extra code
    return this.firestore
      .collection('notices', ref => ref
        .orderBy('time')
        .startAfter(row || 0) //this part helped me reduce code
        .limit(3))
      .snapshotChanges()
}

Elasticsearch

I'm also trying to add elasticsearch to my app so that people can search different notices according to their titles and descriptions which has actually been incredibly difficult. I didn't realize but based on what I've found out today elasticsearch is a whole separate database. It basically saves the data in your original database and indexes them to according to some standard and fetches the data from there when some user is searching for some data.

So, the first thought that goes through my mind is that you would have to continually update the elasticsearch database with your original database.

This elasticsearch feature was a lot more difficult than I imagined. But, I do think learning this skill will help.

Unit testing

I'm also planning to implement unit testing.

Unit testing seems a lot more doable than elasticsearch. I think understanding the logic of why having to test is important came across a more easily than elasticsearch. Simply put, you add test cases so that whenever some new feature is added or changed those test cases ensure that the code is working properly without you having to check the screen constantly.

I read into different types of testing as well such as e2e(end-to-end) testing and integration testing. To my understanding e2e testing is a test that checks to see if your app is working from the frontend all the way to the backend. But because it is fragile only really important features would need to be tested using e2e. The bulk of the testing would be unit testing. So, I'll be focusing my learning on unit testing for the time being.

Accesibility and i18n

Quirky things about Angular

Like I've said in my other post about Angular, there's a lot of jargon and new concepts that you have to learn in Angular.

Observables -RxJS
Dependency Injections
Services

One last finding about Services:
According to the Angular's official docs, components shouldn't fetch or save data directly and should rather focus on presenting data. So, Angular provides a feature called a service that does the data fetching. This is actually very similar to Vue where, to my understanding, it is best practice to make a create a composables files to do the data fetching.

My First Impression of Angular

kim-jos — Thu, 22 Jul 2021 12:37:15 +0000

My first impression of Angular is that it's a lot bulkier than other frameworks. There's more "Angular" syntax that you have to get used to.

You can realize how bulky Angular is just by creating a simple component. When you create an Angular component using the Angular CLI it automatically creates 4 files for you: 1) the html file, 2) the css file, 3) the typescript file, and 4) the test file. I made a couple apps in Vue and all the logic, css, and html are in one file which I think makes it more convenient.

Also Angular has a lot of syntax that you have to get used to. For example, Angular uses a decorator function that generates three metadata properties 1) element selector, 2) templateUrl(html), and 3) styleUrl(CSS styles). In React, you just have to import the css file but in Angular you have to use a decorator function. Although it is done automatically by Angular, the syntax is quite different from anything in React of Vue.

I did read that Angular's advantage is that it's a framework meaning that it has built-in capabilities such as state management, http request functions, server-side rendering, etc. which saves time. Also, the architecture of Angular projects are very similar everywhere.

I did write a couple posts trying to learn Vue but I recently got a job where I have to use Angular. So, I will document my progress learning Angular from now on.

What Does "this" Refer to in JS?

kim-jos — Wed, 14 Jul 2021 12:59:03 +0000

JS's "this" keyword has always caused a lot of confusion for me because it was difficult to understand what it referred to. I will attempt to clear this confusion up for myself and for anyone else reading.

The most important thing we have to remember is that "this" differs according to how a function is called. There are 4 main ways you can call a function which will help us understand how "this" works.

You can call a JS function:

as a function

var age = 100;

function foo () {
 var age = 10;
 console.log(this.age);
}
foo(); // PAY ATTENTION HERE. This part determines what "this" will refer to.

Here, foo() is 100. In this situation, "this" refers to the global object because the function is called as a regular function and all regular functions refer to the global object(window).

as a method

var age = 100;
var player = {
  name: 'Joe',
  age: 35,
  foo: function () {
    console.log(this.age)
  }
}
player.foo(); //PAY ATTENTION HERE. This part determines what "this" will refer to.

Here, player.foo() is 35. In this situation, "this" refers to the the player object because foo() is called as a method attached to player.

as a constructor

function Foo (name) {
  this.name = name;
  console.log(this);
}
var player = new Foo('joe') // PAY ATTENTION HERE. This part determines what "this" will refer to

For constructor functions, a new "this" is created each time and that is what it refers to. So, the "this" in the code example above would refer to the variable "player". You should try console.log and see what you get. You will most likely get {name: 'joe'}.

via apply, call, and bind

let player1 = {
  name: 'joe',
  age: 35,
  printName: function () {
    console.log(this.name);
  }
}

let player2 = {
  name: 'paul',
  age: 30,
}
player1.printName() // 'joe'
player1.printName.call(player2); // 'paul'

We learned that when a function is called as a method, "this" refers to the object it is attached to. But in player1.printName.call(player2), "this" refers to player2 instead of player1. This is possible because of call. With call you can decide what "this" will refer to. It is the same with apply and bind but I won't go into the details in this post.