DEV Community: Dinh Vo

Horizontal and Vertical Scaling In Databases

Dinh Vo — Tue, 06 Sep 2022 14:05:03 +0000

Scaling alters size of a system. In the scaling process, I either compress or expand the system to meet the expected needs. The scaling operation can be achieved by adding resources to meet the smaller expectation in the current system, or by adding a new system in the existing one, or both.
Types of Scaling:

Scaling can be categorised into 2 types:

Vertical Scaling: When new resources are added in the existing system to meet the expectation, it is known as vertical scaling.
Consider a rack of servers and resources that comprises of the existing system. (as shown in the figure). Now when the existing system fails to meet the expected needs, and the expected needs can be met by just adding resources, this is considered as vertical scaling. Vertical scaling is based on the idea of adding more power(CPU, RAM) to existing systems, basically adding more resources. Vertical scaling is not only easy but also cheaper than Horizontal Scaling. It also requires less time to be fixed.
Horizontal Scaling: When new server racks are added in the existing system to meet the higher expectation, it is known as horizontal scaling.
Consider a rack of servers and resources that comprises of the existing system. (as shown in the figure). Now when the existing system fails to meet the expected needs, and the expected needs cannot be met by just adding resources, we need to add completely new servers. This is considered as horizontal scaling.
Horizontal scaling is based on the idea of adding more machines into our pool of resources
Horizontal scaling is difficult and also costlier than Vertical Scaling. It also requires more time to be fixed.

Difference between Horizontal and Vertical Scaling:
Horizontal Scaling

When new server racks are added in the existing system to meet the higher expectation, it is known as horizontal scaling.
It expands the size of the existing system horizontally.
It is easier to upgrade.
It is difficult to implement
It is costlier, as new server racks comprises of a lot of resources
It takes more time to be done

Vertical Scaling

When new resources are added in the existing system to meet the expectation, it is known as vertical scaling
It expands the size of the existing system vertically.
It is harder to upgrade and may involve downtime.
It is easy to implement
It is cheaper as we need to just add new resources
It takes less time to be done

Design principles of Monolithic Architecture — KISS, YAGNI, DRY

Dinh Vo — Tue, 06 Sep 2022 13:08:40 +0000

In this part I'm going to see some example of Reference architectures for Monolithic Architectures.

You can imagine that I'm building an e-commerce application that takes orders from customers, add to basket and checkout the order and so on.

Lets see example Reference Monolithic Architectures.

Reference Monolithic Architecture 1

The application can include several components like GUI and business logics and database persistence layers. The application is deployed as a single monolithic application. For example, a Java web application consists of a single WAR file that runs on a web container such as Tomcat. You can run multiple instances of the application behind a load balancer in order to scale and improve availability.
As a result this solution has a number of benefits:

Simple to develop — you develop in single code base
Simple to deploy — you simply need to deploy only the WAR file
Simple to scale — you can scale the application by running multiple copies of the application behind a load balancer

Reference Monolithic Architecture 2

Here is, I can see different illustrations, again e-commerce application.

Evolve Reference Monolithic Architectures**

And the last one shows how to evolve monolithic architecture.

You can see in this picture, the evolution of monolithic architecture. So its start with standalone 1 application server and database. After that I can split Client application, after that split the business logic and data access and last I split services components in monolithic application.

So as you can see that I will also follow these example reference monolithic architectures and principles and design our own e-commerce application.

Design principles of Monolithic Architecture — KISS, YAGNI, DRY

DRY Principle
DRY is stands for “Don’t Repeat Yourself”
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
This means that, you must try to maintain the behavior of a functionality of the system in a single piece of code, it should not have duplicated code or design item. It’s easier to maintain a code or system that is only in one place, because if you need to change something in the code or system, you just need to change in one place.

KISS Principle
KISS is stands for “Keep It Simple, Stupid”
This principle says about to make your code or system simple. You should avoid unnecessary complexity. A simple code it’s easier to maintain and easier to understand. You can apply this principle in the design and in the implementation of the code. You should eliminate duplicated code, should remove unnecessary features, use names for apis and methods that makes sense and matches their responsibilities.

You also should separate the responsibilities of your applications and the responsibilities from the layers of the systems. Most systems work best if they are kept simple rather than making them complex designs; therefore, simplicity should be a key goal in design and unnecessary complexity should be avoided.

YAGNI Principle
YAGNI is stands for “You Ain’t Gonna Need It”.
Sometimes, I try to think way ahead, into the future of the project, adding some extra features “just in case we need them”. This is Wrong! I don’t need it and in most of the case I can say YAGNI = “You Aren’t Gonna Need It”. This principle is similar to the KISS principle, both of them aim for a simpler solution. The difference between them is that YAGNI focus on removing unnecessary functionality and logic and KISS focus on the complexity.

So with following these principles, I will start to design our e-commerce application architecture. Remember that a clean system, it’s easier to main, easier to understand and for sure it will save your time when you need to change or implement something.

Design the Monolithic Architecture — E-Commerce App — KISS & YAGNI

In this part I'm going to design our e-commerce application with the monolithic architecture step by step. I will iterate the architecture design one by one as per requirements.

In every case, before we design the architecture, We should always start with writing down FRs and NFRs. So lets write down FRs.

Functional Requirements

List products
Filter products as per brand and categories
Put products into the shopping cart
Apply coupon for discounts and see the total cost all for all of the items in shopping cart
Checkout the shopping cart and create an order
List my old orders and order items history Lets write down N-FR.

Non-Functional Requirements

Availability
Scalability Its good to add principles in our picture in order to remember them always.

Principles

DRY
KISS
YAGNI We are going to consider these principles when design our architecture. Now we can consider to Database and Components of e-commerce application.

Database

Database will be single relational database — RDBMS.

Components of E-Commerce

Shop UI
Catalog Service
SC Service
Discount Service
Order Service With following all these considerations, we can design our E-Commerce Monolithic Architecture with applying tech stack as below image;

As you can see that all modules of this traditional web application, such as Shop Front UI, Catalog Service, SC Service, Discount Service and Order Service, are single artifacts in the container.
This monolithic application has a massive codebase that includes all modules. If you introduce new modules to this application, you have to make changes to the existing code and then deploy the artifact with a different code to the Tomcat server. We can develop Java application and output to single WAR Artifact. We can use Oracle or PostgreSQL for our e-commerce monolithic database.

Communication of Components — E-Commerce App — Monolithic Application — Inter-Process Communication
As you know that, monolithic application sitting in the same server with all modules. So we don’t need to make any network call. So it is very easy and fast to communicate between modules of our E -Commerce Monolithic Application.
The communication will be INTER-PROCESS COMMUNICATION.

Inter-process communication is the mechanism provided by the operating system that allows processes to communicate with each other. So that means communication performs by method calls into the code.
This communication could involve a process letting another process know that some event has occurred or transferring of data from one process to another. As you can see that we only use method calls for communication in monolithic architectures.

Transaction Management in Monolithic Architectures
Transaction management in Monolith architecture is quite easy compared to Microservice Architecture. Many frameworks or languages contains some mechanism for transaction management.
These mechanism have a single database of the whole application. They are developed for scenarios where all transactions are running on a single context. In other words, we can simply commit and rollback operations with these mechanism in monolith architectures.
Lets think about our e-commerce domain, We have transactional use case when placing order.
Lets see pseudo code fore place_order method
function place_order() do_payment decrease_stock send_shipment generate_bill update_order
As you can see that we can handle all operations into one method and surround operation in a transactional scope.
By this way, Transactions operated in the transaction scope are kept in memory without writing to the database until they are committed, and if a Rollback is made at any time, all transactions that have been processed so far in the scope are deleted from memory and the transaction is canceled. Without rollback, when Commit is written to the database, the transaction is completed successfully.

Monolith and Microservices Architecture

Dinh Vo — Mon, 05 Sep 2022 15:31:27 +0000

Monolithic architecture

In software engineering, a monolithic pattern refers to a single indivisible unit. The concept of monolithic software lies in different components of an application being combined into a single program on a single platform. Usually, a monolithic app consists of a database, client-side user interface, and server-side application. All the software’s parts are unified and all its functions are managed in one place.

Сomponents of monolithic software are interconnected and interdependent, which helps the software be self-contained. I believe that a monolithic architecture is a perfect solution in some circumstances.

Pros of a monolithic architecture

Simpler development and deployment
In addition, all actions are performed with one directory, which provides for easier deployment.

Fewer cross-cutting concerns
It’s easier to hook up components to these concerns when everything runs in the same app.

Better performance
If built properly, monolithic apps are usually more performant than microservice-based apps. An app with a microservices architecture might need to make 40 API calls to 40 different microservices to load each screen, for example, which obviously results in slower performance. Monolithic apps, in turn, allow faster communication between software components due to shared code and memory.

Cons of a monolithic architecture

Codebase gets cumbersome over time
In the course of time, most products develop and increase in scope, and their structure becomes blurred. The code base starts to look really massive and becomes difficult to understand and modify, especially for new developers. It also gets harder to find side effects and dependencies. With a growing code base quality declines and the integrated development environment (IDE) gets overloaded.

Difficult to adopt new technologies
Adding new technology means rewriting the whole application, which is costly and time-consuming.

Limited agility
In monolithic apps, every small update requires a full redeployment. Thus, all developers have to wait until it’s done. When several teams are working on the same project, agility can be reduced greatly.

The bottom line

Monolithic software architecture can be beneficial if your team is at the founding stage, you’re building an unproven product, and you have no experience with microservices. Monolithic is perfect for startups that need to get a product up and running as soon as possible. However, certain issues mentioned above come with the monolithic package.

Microservice architecture

Microservice is a type of service-oriented software architecture that focuses on building a series of autonomous components that make up an app. Unlike monolithic apps built as a single indivisible unit, microservice apps consist of multiple independent components that are glued together with APIs.

Microservices are important simply because they add unique value in a way of simplification of complexity in systems. By breaking apart your system or application into many smaller parts, you show ways of reducing duplication, increasing cohesion and lowering your coupling between parts, thus making your overall system parts easier to understand, more scalable, and easier to change.

Pros of microservices

Easy to develop, test, and deploy
The biggest advantage of microservices over other architectures is that small single services can be built, tested, and deployed independently. Since a deployment unit is small, it facilitates and speeds up development and release. The last plus here is that the risks of deployment are reduced as developers deploy parts of the software, not the whole app.

Increased agility
With microservices, several teams can work on their services independently and quickly. Each individual part of an application can be built independently due to the decoupling of microservice components. For example, you may have a team of 100 people working on the whole app (like in the monolithic approach), or you can have 10 teams of 10 people developing different services for the app. Let’s imagine this visually.

Increased agility allows developers to update system components without bringing down the application. Moreover, agility provides a safer deployment process and improved uptime. New features can be added as needed without waiting for the entire app to launch.

Ability to scale horizontally
Vertical scaling (running the same software but on bigger machines) can be limited by the capacity of each service. But horizontal scaling (creating more services in the same pool) isn’t limited and can run dynamically with microservices. Furthermore, horizontal scaling can be completely automated.

Cons of microservices

Complexity
Splitting an application into independent microservices entails more artifacts to manage. This type of architecture requires careful planning, enormous effort, team resources, and skills. The reasons for high complexity are the following:

Increased demand for automation, as every service should be tested and monitored
Available tools don’t work with service dependencies
Data consistency and transaction management becomes harder as each service has a database

Security concerns
In a microservices application, each functionality that communicates externally via an API increases the chance of attacks. These attacks can happen only if proper security measurements aren’t implemented when building an app.

Different programming languages
The ability to choose different programming languages is two sides of the same coin. Using different languages make deployment more difficult. In addition, it’s harder to switch programmers between development phases when each service is written in a different language.

The bottom line

Microservices are good, but not for all types of apps. This pattern works great for evolving applications and complex systems. Consider choosing a microservices architecture when you have multiple experienced teams and when the app is complex enough to break it into services. When an application is large and needs to be flexible and scalable, microservices are beneficial.

Monolithic apps consist of interdependent, indivisible units and feature very low development speed. Microservices are very small, loosely coupled independent services and feature rapid continuous development.

Binary search tree (BST) - Insertion

Dinh Vo — Tue, 09 Aug 2022 15:20:00 +0000

Để insert một node vào BST, chúng ta cần tuân thủ 4 quy tắc sau:

Các node mới luôn được chèn vào leaf node.
Bắt đầu từ node root và gọi đệ quy cho đến khi pointer left, hoặc right == null.
Nếu value của node hiện tại nhỏ hơn value của node mới, thì chuyển sang node bên phải của node hiện tại, còn lại chuyển sang node bên trái.
Nếu node hiện tại là null, hãy insert node mới đó bằng cách gán node hiện tại = node mới

<script>

// javascript program to demonstrate insert 
// operation in binary search tree
// BST node
class Node
{
    constructor()
    {
        this.key = 0;
        this.left = null;
        this.right = null;
    }
};

// Utility function to create a new node
function newNode(data)
{
    var temp = new Node();
    temp.key = data;
    temp.left = null;
    temp.right = null;
    return temp;
}

// A utility function to insert a new
// Node with given key in BST
function insert(root, key)
{

    // Create a new Node containing
    // the new element
    var newnode = newNode(key);

    // Pointer to start traversing from root and
    // traverses downward path to search
    // where the new node to be inserted
    var x = root;

    // Pointer y maintains the trailing
    // pointer of x
    var y = null;

    while (x != null)
    {
        y = x;
        if (key < x.key)
            x = x.left;
        else
            x = x.right;
    }

    // If the root is null i.e the tree is empty
    // The new node is the root node
    if (y == null)
        y = newnode;

    // If the new key is less than the leaf node key
    // Assign the new node to be its left child
    else if (key < y.key)
        y.left = newnode;

    // else assign the new node its right child
    else
        y.right = newnode;

    // Returns the pointer where the
    // new node is inserted
    return y;
}

// A utility function to do inorder
// traversal of BST
function Inorder(root)
{
    if (root == null)
        return;
    else
    {
        Inorder(root.left);
        document.write( root.key +" ");
        Inorder(root.right);
    }
}

// Driver code
/* Let us create following BST
        50
    / \
    30 70
    / \ / \
20 40 60 80 */
var root = null;
root = insert(root, 50);
insert(root, 30);
insert(root, 20);
insert(root, 40);
insert(root, 70);
insert(root, 60);
insert(root, 80);
// Print inorder traversal of the BST
Inorder(root);

// This code is contributed by itsok.
</script>

Output
20 30 40 50 60 70 80

Cách sử dụng useMemo()

Dinh Vo — Wed, 03 Aug 2022 13:32:00 +0000

useMemo() được build bởi React hook và chấp nhận 2 argument- một function và mảng dependencies.
const memoizedResult = useMemo(compute, dependencies);
Trong quá trình render lần đầu, useMemo(compute,dependencies) ngay lập tức gọi compute, ghi nhớ value đã return cho vào memorizes, và trả về component.
Nếu trong suốt quá trình renderings, các dependencies không thay đổi, useMemo() không gọi compute mà return memorized value.
Nhưng nếu các dependencies thay đổi trong quá trình re-rendering, useMemo() sẽ gọi compute, nó sẽ update một value mới vào memorizes, và trả về value đó.
Ví dụ useMemo()
Một component nhằm tính giai thừa của một số.

import { useState } from 'react';
export function CalculateFactorial() {
  const [number, setNumber] = useState(1);
  const [inc, setInc] = useState(0);
  const factorial = factorialOf(number);
  const onChange = event => {
    setNumber(Number(event.target.value));
  };
  const onClick = () => setInc(i => i + 1);

  return (
    <div>
      Factorial of 
      <input type="number" value={number} onChange={onChange} />
      is {factorial}
      <button onClick={onClick}>Re-render</button>
    </div>
  );
}
function factorialOf(n) {
  console.log('factorialOf(n) called!');
  return n <= 0 ? 1 : n * factorialOf(n - 1);
}

Mỗi khi bạn thay đổi giá trị input, factorialOf(n) và factorialOf(n) được gọi.
Ben cạnh đó, mỗi lần bạn nhấn re-render, set state inc sẽ được update và component <CalculateFactorial/> sẽ được re-rendering. Nhưng, trong lần render thứ 2, factorialOf(n) được gọi lại lần nữa.
Vậy làm thế nào có thể ghi nhớ factorial khi componnent re-renders?
Bằng cách sử dụng useMemo(()=>factorialOf(number),[number]) thay vì đơn giản factorialOf(number), React sẽ ghi nhớ factorial
Ví dụ

import { useState, useMemo } from 'react';
export function CalculateFactorial() {
  const [number, setNumber] = useState(1);
  const [inc, setInc] = useState(0);
  const factorial = useMemo(() => factorialOf(number), [number]);
  const onChange = event => {
    setNumber(Number(event.target.value));
  };
  const onClick = () => setInc(i => i + 1);

  return (
    <div>
      Factorial of 
      <input type="number" value={number} onChange={onChange} />
      is {factorial}
      <button onClick={onClick}>Re-render</button>
    </div>
  );
}
function factorialOf(n) {
  console.log('factorialOf(n) called!');
  return n <= 0 ? 1 : n * factorialOf(n - 1);
}

Mỗi lần ấn button Re-render, factorial(n) không được in ra màn hình console bởi vì useMemo returns memorized của factorial
Kết luận
useMemo(()=>computation(a,b),[a,b]) cho phép bạn ghi nhớ các phép tính lưu vào vùng nhớ memorize. Với các dependencies [a,b] giống nhau, hook sẽ trả về memorized value mà không cần gọi computation(a,b)

Proxy Pattern trong Javascript

Dinh Vo — Sat, 30 Jul 2022 17:38:14 +0000

Với một Proxy object, chúng ta có quyền kiểm soát các tương tác với một object nhất định, ví dụ: getting một value hoặc setting một value.

Hãy tạo một object person, đại diện là John Doe.

const person = {
  name: "John Doe",
  age: 42,
  nationality: "American"
};

Thay vì tương tác trực tiếp với object này, tôi muốn tương tác với một proxy object. Trong javascript, tôi có thể tạo một proxy bằng cách sử dụng từ khóa new Proxy

const person = {
  name: "John Doe",
  age: 42,
  nationality: "American"
};

const personProxy = new Proxy(person, {});

Argument thứ 2 của proxy là một object đại diện được gọi là handler. Trong handler object, tôi có thể xác định các hành vi cụ thể dựa trên loại tương tác. Mặc dù có nhiều methods mà tôi có thể thêm vào Proxy handler, 2 method phổ biến nhất là get và set:

get: được gọi khi cố gắng access một property
set được gọi khi muốn modify một property Quy trình sẽ xảy ra như xau: Thay vì tương tác trực tiếp với object person, tôi sẽ tương tác với personProxy. Hãy thêm các handlers vào proxyHandler. Khi muốn modify một property, do đó gọi method set trên proxy, tôi muốn proxy in value cũ và value mới, sau đó thực hiện ghi đè value của property. Khi cố gắng access một property, hãy gọi method get trên Proxy, tôi muốn proxy ghi lại một contains chứa key và value của property.

const personProxy = new Proxy(person, {
  get: (obj, prop) => {
    console.log(`The value of ${prop} is ${obj[prop]}`);
  },
  set: (obj, prop, value) => {
    console.log(`Changed ${prop} from ${obj[prop]} to ${value}`);
    obj[prop] = value;
  }
});

Tuyệt hãy xem đoạn code dưới dây, điều gì sẽ xảy ra?

const person = {
  name: "John Doe",
  age: 42,
  nationality: "American"
};

const personProxy = new Proxy(person, {
  get: (obj, prop) => {
    console.log(`The value of ${prop} is ${obj[prop]}`);
  },
  set: (obj, prop, value) => {
    console.log(`Changed ${prop} from ${obj[prop]} to ${value}`);
    obj[prop] = value;
    return true;
  }
});

personProxy.name; //The value of name is John Doe 
personProxy.age = 43; //Changed age from 42 to 43

Khi access name, proxy trả về một câu: The value of name is John Doe
khi modify age, proxy in Changed age from 42 to 43

Ngoài ra có thể bắt các validation của method proxy

const personProxy = new Proxy(person, {
  get: (obj, prop) => {
    if (!obj[prop]) {
      console.log(
        `Hmm.. this property doesn't seem to exist on the target object`
      );
    } else {
      console.log(`The value of ${prop} is ${obj[prop]}`);
    }
  },
  set: (obj, prop, value) => {
    if (prop === "age" && typeof value !== "number") {
      console.log(`Sorry, you can only pass numeric values for age.`);
    } else if (prop === "name" && value.length < 2) {
      console.log(`You need to provide a valid name.`);
    } else {
      console.log(`Changed ${prop} from ${obj[prop]} to ${value}.`);
      obj[prop] = value;
    }
  }
});

Hãy xem đoạn code dưới dây, điều gì sẽ xảy ra?

const person = {
  name: "John Doe",
  age: 42,
  nationality: "American"
};

const personProxy = new Proxy(person, {
  get: (obj, prop) => {
    if (!obj[prop]) {
      console.log(`Hmm.. this property doesn't seem to exist`);
    } else {
      console.log(`The value of ${prop} is ${obj[prop]}`);
    }
  },
  set: (obj, prop, value) => {
    if (prop === "age" && typeof value !== "number") {
      console.log(`Sorry, you can only pass numeric values for age.`);
    } else if (prop === "name" && value.length < 2) {
      console.log(`You need to provide a valid name.`);
    } else {
      console.log(`Changed ${prop} from ${obj[prop]} to ${value}.`);
      obj[prop] = value;
    }
    return true;
  }
});

personProxy.nonExistentProperty; //Hmm.. this property doesn't seem to exist
personProxy.age = "44"; //Sorry, you can only pass numeric values for age. 
personProxy.name = ""; //You need to provide a valid name.

Proxy made sure tôi không sủa đổi object person với các value không hợp lệ, điều này giúp tôi giữ cho dữ liệu của tôi tinh khiết(data pure)
Reflect
Js cung cấp một object gọi là Reflect, giúp tôi thao tác với đối tượng đích dễ dàng hơn khi làm việc với proxy.
Trước đây, tôi muốn modify và acces property trên một object bên trong proxy thông qua get, set bằng ky hiệu {}. Thay vào đó, tôi có thể sử dụng Reflect. Methods trên Reflect có cùng tên với các methods trên object đang xử lý.
Thay vì access property thông qua obj[prop], tôi có thể access hoặc modify property thông qua Reflect.get() và Reflect.set(). Các methods nhận các arguments dưới dạng methods trên handle obejct.

const personProxy = new Proxy(person, {
  get: (obj, prop) => {
    console.log(`The value of ${prop} is ${Reflect.get(obj, prop)}`);
  },
  set: (obj, prop, value) => {
    console.log(`Changed ${prop} from ${obj[prop]} to ${value}`);
    Reflect.set(obj, prop, value);
  }
});

Hãy xem đoạn code dưới dây:

const person = {
  name: "John Doe",
  age: 42,
  nationality: "American"
};

const personProxy = new Proxy(person, {
  get: (obj, prop) => {
    console.log(`The value of ${prop} is ${Reflect.get(obj, prop)}`);
  },
  set: (obj, prop, value) => {
    console.log(`Changed ${prop} from ${obj[prop]} to ${value}`);
    return Reflect.set(obj, prop, value);
  }
});

personProxy.name; //The value of name is John Doe 
personProxy.age = 43; //The value of name is John Doe 
personProxy.name = "Jane Doe"; //The value of name is John Doe

Proxy là một cách hiệu quả để control các behavior của một object. Một proxy có thể có nhiều use-cases: nó giúp validation, formatting, notifications, hoặc debugging.
Việc lạm dụng proxy hoặc thực hiện các thao tác nặng trên mỗi handler method có thể ảnh hưởng đến performance của app. Tốt nhất cũng không nên sử dụng proxy cho các đoạn code quan trọng về hiệu suất.