I just finished reading the chapter on *"Design Consistent Hashing"*  from the book *"System Design Interview – An Insider's Guide"* by Alex Xu and found this concept very fascinating that I felt like writing this post to help cement what I've learned, and hopefully help you too.

In system design, when we scale horizontally (aka throw in more servers to handle more traffic), we run into a big question: **how do we split up the requests/data between all those servers evenly and efficiently?** One clever solution is something called consistent hashing. But before we dive into how it works, let's step back for a second and look at the actual problem it tries to solve.
## The rehashing problem

When we have `N` cache servers, a common way to balance the load is by using a simple hashing formula:

```ini
serverIndex = hash(key) % N, where N is the size of the server pool
```

This basically tells us which server a key should go to, based on its hash value and the total number of servers. Let's say we have 4 servers and 8 keys. Here's an example where each key is mapped to a server using the above formula:

| key  | hash     | hash % 4 |
| ---- | -------- | -------- |
| key0 | 18358617 | 1        |
| key1 | 26143584 | 0        |
| key2 | 18131146 | 2        |
| key3 | 35863496 | 0        |
| key4 | 34085809 | 1        |
| key5 | 27581703 | 3        |
| key6 | 38164978 | 2        |
| key7 | 22530351 | 3        |

From the table above, if we want to get the value for `key1`, the client will use `hash(key1) % 4`, which equals to `0`, so the request goes to **server 0**. The same logic applies to other keys.
![Keys distribution with 4 servers](https://i.postimg.cc/qM9MPx0B/Pasted-image-20250727215531.png)
This method works well as long as the number of servers stays the same, and the data distribution is even. But here's the catch: if we add or remove servers, things break down. For instance, let's say **server 1 goes offline**, and now we only have **3 servers**. We're still using the same hash function, so each key still gets the same hash value, but because we're now doing `hash(key1) % 3`, most keys will be assigned to **different servers**. Here’s how the new server assignments would look after reducing the pool to 3 servers:

| key  | hash     | hash % 3 |
| ---- | -------- | -------- |
| key0 | 18358617 | 0        |
| key1 | 26143584 | 0        |
| key2 | 18131146 | 1        |
| key3 | 35863496 | 2        |
| key4 | 34085809 | 1        |
| key5 | 27581703 | 0        |
| key6 | 38164978 | 1        |
| key7 | 22530351 | 0        |

![Keys Distribution with 3 servers](https://i.postimg.cc/fbksk3Mq/Pasted-image-20250727220440.png)
As shown in the figure above, most of the keys are now mapped to different servers, not just the ones that were originally stored on the failed server (server 1).
You can tell where each key originally belonged by its color. This highlight an important issue: even though the data itself hasn't changed, clients may now be looking in the wrong places. That leads to a surge in cache miss, increased latency, and unnecessary load on the system.
This is exactly the kind of problem that **consistent hashing** is designed to solve.
## Consistent Hashing

> “**Consistent hashing** is a special kind of [hashing](https://en.wikipedia.org/wiki/Hash_function "Hash function") technique such that when a [hash table](https://en.wikipedia.org/wiki/Hash_table "Hash table") is resized, only n/m keys need to be remapped on average where n is the number of keys and m is the number of slots. In contrast, in most traditional hash tables, a change in the number of array slots causes nearly all keys to be remapped.”
> — [Wikipedia](https://en.wikipedia.org/wiki/Consistent_hashing)
### Hash space and hash ring
Now that we know what consistent hashing is, let's see how it actually works behind the scenes.
When a hash function like SHA-1 is used, it maps every input (like a server or a key) to a number in a huge range, from `0` to `2^160-1`. We call this range the **hash space**.
![Image](https://i.postimg.cc/X730d1VC/Pasted-image-20250727224734.png)
Since this space is too large to draw as a straight line, we often imagine it as a circle, where the smallest and largest values are next to each other. This circle is called the **hash ring**.
![Image](https://i.postimg.cc/VkZQyYXq/Pasted-image-20250727225459.png)
### Hash servers
Now we treat the servers (typically their IPs or names) as input to the same hash function `f`. The resulting hash values are then mapped onto the ring, as shown in the figure below.
![Image](https://i.postimg.cc/hPC3v2hg/Pasted-image-20250728220650.png)
### Hash keys
Just like we did with the servers, we now place the 4 keys (key0 to key3) onto the hash ring, as shown below.
![Image](https://i.postimg.cc/7LNzPWYn/Pasted-image-20250728221125.png)
### Server lookup
So how do we know which server stores which key? It's simple: just start from the key's position on the ring, then move clockwise until we hit a server. For example, in the figure below: key0 lands on server0, key1 on server 1, key2 on server2, and key3 on server 3.
![Image](https://i.postimg.cc/D0RJYVBn/Pasted-image-20250728224544.png)
### Add a server
This approach solves the problem of too many keys being moved when we add a new server.  
In the diagram below, adding server 4 only affects key0, it's the first server that key0 hits when we go clockwise.  
The rest (key1, key2, key3) stay where they are. Neat, right?
![Image](https://i.postimg.cc/ryD9gqp6/Pasted-image-20250729184306.png)
### Remove a server
In the same way, if a server goes offline, only a small number of keys are affected. In the diagram below, when _server 1_ is removed, only _key1_ moves to _server 2_. All other keys stay where they are.
![image](https://i.postimg.cc/nhGKMz3m/Pasted-image-20250730111246.png)
### Issues in the basic approach
The basic steps of consistent hashing are:
- Map servers and keys onto the ring using a uniformly distributed hash function.
- From the position of a key, go clockwise until the first server is found that server will store the key.
However, there are two main issues with this approach:
1. When a server is added or removed, it's difficult to keep the ring evenly partitioned. For example, in the situation above where _server 1_ is removed, the segment assigned to _server 2_ becomes much larger than those of _server 0_ and _server 3_.
2. As a result, keys are distributed unevenly. _Server 2_ ends up storing most of the keys, while _server 0_ and _server 3_ hold very few or none.
That’s where _virtual nodes_ (or _replicas_) come in.
### Virtual Nodes
Now, instead of being represented by a single node, each server is represented by **multiple virtual nodes** on the ring. As shown in the figure below, both _server 1_ and _server 3_ have three virtual nodes each. In real-world systems, the number of virtual nodes per server is usually much higher.
For example, _server 0_ is now represented by _s0-0_, _s0-1_, and _s0-2_ on the ring. Similarly, _s1-0_, _s1-1_, and _s1-2_ represent _server 1_. Each of these virtual nodes is responsible for a portion of the hash ring.
![Image](https://i.postimg.cc/YSX1fPKq/Pasted-image-20250803232213.png)
The same method is used to determine where a key is stored: go clockwise from the key’s position until a virtual node is found. In the figure below, we can see that _k0_ lands on _s1-1_, which belongs to _server 1_.
![Image](https://i.postimg.cc/k5MQSmHp/Pasted-image-20250803232540.png)
Increasing the number of virtual nodes helps balance the distribution of keys across servers. This is because more virtual nodes reduce variation, making the distribution more even.
For example, a study shows that with 100–200 virtual nodes, the standard deviation drops to 5–10% of the mean. While adding more virtual nodes improves balance, it also increases metadata overhead. So the number of virtual nodes should be tuned based on system needs.
## TL;DR:
Consistent hashing is a smart way to distribute data across servers with minimal disruption when servers are added or removed. By mapping keys and servers onto a hash ring — and using virtual nodes — we can achieve better load balancing and system scalability with fewer cache misses. It’s a core concept behind many scalable systems today, and definitely worth understanding deeply.

In system design, when we scale horizontally (aka throw in more servers to handle more traffic), we run into a big question: how do we split up the requests/data between all those servers evenly and efficiently? One clever solution is something called consistent hashing.

Consistent Hashing

Khi sử dụng JavaScript lập trình web, chúng ta nhiều khi gặp một số trường hợp cần lưu trữ thông tin phía client như thông tin người dùng, theme của trang web, hay một số thông tin hữu dụng khác trong quá trình người dùng thao tác với website. JavaScript cung cấp cho chúng ta ba cơ chế để lưu trữ các thông tin này: **Local Storage, Session Storage và Cookies.** Ở bài viết này, mình sẽ giới thiệu cho các bạn về ba cơ chế này cũng như sự khác biệt giữa chúng nhé.

## Local Storage

Local Storage có thể lưu trữ thông tin giữa các session khác nhau, session ở đây có nghĩa là phiên làm việc của website, dữ liệu đã lưu vào local storage sẽ không bị xóa đi sau khi session kết thúc (có thể hiểu là khi bạn đóng website). Với tính chất này, local storage thường được sử dụng để lưu các settings, user preferences của một website.

Phương thức lưu trữ này có thể lưu đến 10MB dữ liệu, lớn nhất trong 3 loại nhưng có một nhược điểm đó là local storage chỉ có thể lưu được kiểu dữ liệu chuỗi (String).

**Cách lưu và đọc của Local Storage:**

```js
// Lưu dữ liệu vào Local Storage
localStorage.setItem('name', 'koalalikecode');

// Đọc dữ liệu từ Local Storage
const name = localStorage.getItem('name');
console.log(name); // In ra: koalalikecode
```

**Xóa Local Storage:**

```js
// Xóa một biến
localStorage.removeItem(key);

// Xóa toàn bộ trong Local Storage
localStorage.clear();
```

## Session Storage

Session Storage gần như giống hệt Local Storage trừ một điểm là dữ liệu lưu trữ bởi Session Storage sẽ bị xóa sau khi phiên làm dịch của website kết thúc, tức là khi người dùng đóng tab trên trình duyệt.

Cũng từ lý do như trên, mỗi lần chúng ta bật một tab mới là sẽ xuất hiện một session mới ứng với tab đó, vì vậy có thể cùng một trang web nhưng 2 tab khác nhau thì dữ liệu trong session storage cũng sẽ khác nhau.

Session Storage thường ứng dụng để lưu các dữ liệu chỉ tồn tại ở phiên làm việc đó, chẳng hạn như thông tin phiên làm việc của người dùng, hay một số web cần check vị trí của người dùng.

**Cách lưu và đọc của Session Storage**

```js
// Lưu dữ liệu vào Session Storage
sessionStorage.setItem('name', 'koalalikecode');

// Đọc dữ liệu từ Session
const name = sessionStorage.getItem('name');
console.log(name); // Output: koalalikecode
```

**Xóa Session Storage:**

```js
// Xóa một biến
sessionStorage.removeItem(key);

// Xóa toàn bộ trong Session Storage
sessionStorage.clear();
```

## Cookies 🍪🍪🍪

Cookies là các dữ liệu do người dùng tạo ra trong quá trình sử dụng trang web và được lưu ở local machine. Cơ chế này giúp nâng cao trải nghiệm sử dụng web thông qua việc lưu một số thông tin hữu ích như thông tin đăng nhập của người dùng, ngôn ngữ duyệt web,…

Khác với Local Storage và Session Storage chỉ access được dữ liệu ở phía client, cookies cho phép chúng ta access được cả ở client và server (khi tạo một http request thì cookies của browser sẽ được attach vào header Cookie, từ đó phía server có thể parse header này và get được data cookie).

Cookies cho phép lưu trữ tối đa khoảng 4KB và khác với local storage, nó cho phép lưu trữ cả các kiểu dữ liệu khác ngoài chuỗi (có thể là array, object,…). Ngoài ra, cookies có thời gian expire cụ thể, có thể là do lập trình viên cung cấp.

**Cách tạo cookies và đọc cookies**

```js
// Tạo cookies 
document.cookie = 'username=koalalikecode; expires=Fri, 21 Apr 2023 8:00:00 UTC';

// Đọc cookies
let x = document.cookie;
```

Ở ví dụ trên, ta có thể thấy, ngoài giá trị key-value `username`, ta còn có thể cung cấp thời hạn cookies kết thúc bằng `expires` key và value là một thời gian cụ thể. Khi đọc cookies, `document.cookie` sẽ trả lại tất cả cookie trong một chuỗi tring kiểu như: `cookie1 = giá trị; cookie2 = giá trị; cookie3 = giá trị;`

## Bảng so sánh
|Local Storage|Session Storage|Cookies|
|---|---|---|
|Dung lượng lưu trữ 5MB/10MB|Dung lượng lưu trữ 5MB|Dung lượng lưu trữ 4KB|
|Vô thời hạn, chỉ có thể xóa bằng javascript hoặc thủ công|Chỉ tồn tại trong phạm vị session, tab trình duyệt|Cookies hết hạn dựa trên thiết lập ban đầu|
|Chỉ có thể đọc được ở phía client|Chỉ có thể đọc được ở phía client|Có thể đọc được ở cả client và server|
|Không có dữ liệu truyền về server|Không có dữ liệu truyền về server|Có tồn tại dữ liệu truyền về server|


JavaScript cung cấp cho chúng ta ba cơ chế để lưu trữ các thông tin này: Local Storage, Session Storage và Cookies. Ở bài viết này, mình sẽ giới thiệu cho các bạn về ba cơ chế này cũng như sự khác biệt giữa chúng nhé.

Local Storage, Session Storage và Cookies trong JavaScript

## What is CI/CD?
### Overview
CI/CD is a method to frequently deliver apps to customers by introducing automation into the stages of app development. The main concepts attributed to CI/CD are continuous integration, continuous delivery, and continuous deployment. CI/CD is a solution to the problems integrating new code can cause for development and operations teams (AKA "integration hell"). 
Specifically, CI/CD introduces ongoing automation and continuous monitoring throughout the lifecycle of apps, from integration and testing phases to delivery and deployment. Taken together, these connected practices are often referred to as a "CI/CD pipeline".
### Continuous integration
Developers practicing continuous integration merge their changes back to the main branch as often as possible. The developer's changes are validated by creating a build and running automated tests against the build. By doing so, you avoid integration challenges that can happen when waiting for release day to merge changes into the release branch.
Continuous integration puts a great emphasis on testing automation to check that the application is not broken whenever new commits are integrated into the main branch.
### Continuous delivery
>[Continuous delivery](https://www.atlassian.com/continuous-delivery) is an extension of continuous integration since it automatically deploys all code changes to a testing and/or production environment after the build stage.
This means that on top of automated testing, you have an automated release process and you can deploy your application any time by clicking a button.
In theory, with continuous delivery, you can decide to release daily, weekly, fortnightly, or whatever suits your business requirements. However, if you truly want to get the benefits of continuous delivery, you should deploy to production as early as possible to make sure that you release small batches that are easy to troubleshoot in case of a problem.
### Continuous deployment
Continuous deployment goes one step further than continuous delivery. With this practice, every change that passes all stages of your production pipeline is released to your customers. There's no human intervention, and only a failed test will prevent a new change to be deployed to production.
Continuous deployment is an excellent way to accelerate the feedback loop with your customers and take pressure off the team as there isn't a "release day" anymore. Developers can focus on building software, and they see their work go live minutes after they've finished working on it.
![](https://wac-cdn.atlassian.com/dam/jcr:b2a6d1a7-1a60-4c77-aa30-f3eb675d6ad6/ci%20cd%20asset%20updates%20.007.png?cdnVersion=1309)
### Some popular CI/CD tools
- [GitLab CI/CD](https://docs.gitlab.com/ee/ci/)
- [Azure DevOps](https://azure.microsoft.com/en-us/services/devops/pipelines/)
- [GitHub's Actions](https://github.com/features/actions)
- [CircleCI](https://circleci.com/)
- [Jenkins](https://www.jenkins.io/)
- [Travis CI](https://travis-ci.org/)
- [Bitbucket pipeline](https://bitbucket.org/product/features/pipelines)
- [TeamCity](https://www.jetbrains.com/teamcity/)
## Jenkins
### What Is Jenkins?
Jenkins is an open-source solution comprising an automation server to enable continuous integration and continuous delivery (CI/CD), automating the various stages of software development such as build, test, and deployment.
![](https://images.spiceworks.com/wp-content/uploads/2022/07/05133421/A-Pictorial-Representation-of-the-Jenkins-Interface.png)
### Key Features of Jenkins
![](https://images.spiceworks.com/wp-content/uploads/2022/07/20050527/Key-Features-of-Jenkins.png)
#### A variety of plugins
- Jenkins plugins are extensions to the Jenkins system. Providing integration points for [CI/CD tools,](https://www.spiceworks.com/tech/devops/articles/best-cicd-tools/ "CI/CD tools,") sources and destinations is among the most prevalent plugin applications.
- They also aid with the expansion of Jenkins’ capabilities as well as the integration of Jenkins with other software. Plugins may be downloaded and installed using the Jenkins Web UI or CLI from the Jenkins Plugin repository.
- Nowadays, the Jenkins community reports that there are around 1,500 plugins available for a variety of applications.
#### Simple installation and configuration
- Jenkins is a self-contained Java software that doesn’t care about the platform it’s running on. It runs on all standard operating systems, including Windows, Unix versions, and Mac OS. 
- Jenkins’ online interface is simple to set up and configure, including error checks and a built-in help feature.
#### Extensibility
Jenkins can be extended via its plugin architecture, providing nearly infinite possibilities for what Jenkins can do.
### Jenkins Pipeline
> Jenkins Pipeline (or simply "Pipeline" with a capital "P") is a suite of plugins which supports implementing and integrating _continuous delivery pipelines_ into Jenkins.
#### Jenkinsfile
The definition of a Jenkins Pipeline is written into a text file (called a [`Jenkinsfile`](https://www.jenkins.io/doc/book/pipeline/jenkinsfile)) which in turn can be committed to a project’s source control repository.
A `Jenkinsfile` can be written using two types of syntax — Declarative and Scripted.
Declarative and Scripted Pipelines are constructed fundamentally differently. Declarative Pipeline is a more recent feature of Jenkins Pipeline which:
- provides richer syntactical features over Scripted Pipeline syntax, and
- is designed to make writing and reading Pipeline code easier.
#### Pipeline concepts
##### Pipeline
A Pipeline is a user-defined model of a CD pipeline. A Pipeline’s code defines your entire build process, which typically includes stages for building an application, testing it and then delivering it.
##### Node
A node is a machine which is part of the Jenkins environment and is capable of executing a Pipeline.
Also, a `node` block is a [key part of Scripted Pipeline syntax](https://www.jenkins.io/doc/book/pipeline/#scripted-pipeline-fundamentals).
##### Stage
A `stage` block defines a conceptually distinct subset of tasks performed through the entire Pipeline (e.g. "Build", "Test" and "Deploy" stages), which is used by many plugins to visualize or present Jenkins Pipeline status/progress. [[6](https://www.jenkins.io/doc/book/pipeline/#_footnotedef_6 "View footnote.")]
##### Step
A single task. Fundamentally, a step tells Jenkins _what_ to do at a particular point in time (or "step" in the process). For example, to execute the shell command `make`, use the `sh` step: `sh 'make'`. When a plugin extends the Pipeline DSL, [[1](https://www.jenkins.io/doc/book/pipeline/#_footnotedef_1 "View footnote.")] that typically means the plugin has implemented a new _step_.
```groovy
Jenkinsfile (Declarative Pipeline)
pipeline {
 agent any 
 stages {
 stage('Build') { 
 steps {
 // 
 }
 }
 stage('Test') { 
 steps {
 // 
 }
 }
 stage('Deploy') { 
 steps {
 // 
 }
 }
 }
}
```
## Github Actions
GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. You can create workflows that build and test every pull request to your repository, or deploy merged pull requests to production.
### What is a GitHub Actions workflow?
A _GitHub Actions workflow_ is a process that you set up in your repository to automate software-development lifecycle tasks, including GitHub Actions. With a workflow, you can build, test, package, release, and deploy any project on GitHub.
To create a workflow, you add actions to a .yml file in the `.github/workflows` directory in your GitHub repository.
### The components of GitHub Actions
![](https://learn.microsoft.com/en-us/training/github/github-actions-automate-tasks/media/github-actions-workflow-components.png)
#### Workflows
A workflow is an automated process that you add to your repository. A workflow needs to have at least one job, and different events can trigger it. You can use it to build, test, package, release, or deploy your repository's project on GitHub.
#### Jobs
The job is the first major component within the workflow. A job is a section of the workflow that will be associated with a runner. A runner can be GitHub-hosted or self-hosted, and the job can run on a machine or in a container. You'll specify the runner with the `runs-on:` attribute. Here, you're telling the workflow to run this job on `ubuntu-latest`. We'll talk more about runners in the next unit.
#### Steps
A step is an individual task that can run commands in a job. In our preceding example, the step uses the action `actions/checkout@v2` to check out the repository. What's interesting is the `uses: ./action-a` value. This is the path to the container action that you'll build in an `action.yml` file.
#### Actions
The actions inside your workflow are the standalone commands that are executed. These standalone commands can reference GitHub actions such as using your own custom actions, or community actions like the one we use in the preceding example, `actions/checkout@v2`. You can also run commands such as `run: npm install -g bats` to execute a command on the runner.
## GitHub Actions vs Jenkins
| | | |
|---|---|---|
|**CI/CD tool**|**Pros**|**Cons**|
|**Jenkins**|– Highly customizable and extensible. – Large community and ecosystem of plugins. – Supports many programming languages, integrations and platforms. – Can be deployed locally, on-premise or in the cloud (using different resources like VPS, K8s and more).|– Steep learning curve. – Requires significant effort to set up and maintain. – Dedicated resources like DevOps team and others. – Plugins ecosystem can be complex and difficult to navigate. – Upgrade process and plugin version control can be frustrating. – Can be expensive for large-scale and high availability deployments|
|**GitHub Actions**|– Native integration with GitHub. – Simple and easy-to-use YAML syntax. – Growing library of pre-built actions. – Scalable and cost-effective|– Limited plugin support compared to Jenkins. – Limited customization options. – Security concerns due to requiring access to GitHub repository. – Relatively new, so may not have all features required by some organizations. – Can be expensive/costly if the execution of the Jobs takes a long time because the pricing is based on the execution time (minutes)|

CI/CD is a method to frequently deliver apps to customers by introducing automation into the stages of app development. The main concepts attributed to CI/CD are continuous integration, continuous delivery, and continuous deployment.

CI-CD and Tools

Khi nhắc đến xử lý bất đồng bộ trong JavaScript, chắc ai cũng liên tưởng đến một vấn đề của việc sử dụng callback function, đó là **callback hell**, đại khái trông nó sẽ như [thế này](https://images.viblo.asia/2b67c194-4ef8-4879-a44b-410c1b4bddee.png). Qua thời gian, callback bộc lộ nhiều yếu điểm, thời gian hoàn tất tăng lên do các hàm phải "xếp hàng" để chờ nhau thực hiện, cấu trúc code trở nên khá rối và khó bảo trì.

May mắn thay, trong phiên bản ES6, JavaScript mang đến cho người dùng khái niệm **Promise**. Việc viết code bất đồng bộ với cấu trúc Promise và .then() trở nên rất rõ ràng và tường minh, vì vậy cộng đồng nhanh chóng chuyển sang sử dụng Promise thay thế callbacks.

Và ở phiên bản ES7, với sự xuất hiện của **Aync/Await**, viết JavaScript bất đồng bộ còn trở nên dễ dàng và tốt hơn nữa.

## Async/Await là gì?

**Async/Await** là một cách mới để viết code bất đồng bộ, được **Javascript** giới thiệu từ bản cập nhật **ES7**. Nó được xây dựng trên **Promise** và tương thích với tất cả **Promise** dựa trên API. Trong đó được cấu tạo từ 2 thành phần: **async function** và **await**.

### 1. Async functions

Với từ khóa async, chúng ta có thể khai báo hàm bất đồng bộ. Các hàm này có giá trị trả về là một Promise. Mình sẽ minh họa về async với ví dụ sau:

```javascript
async function gdscHust() {
  return "Welcome to GDSC-HUST!"
  //tương đương với return new Promise(resolve => resolve("Welcome to GDSC-HUST!"))
}

gdscHust().then(
    res => console.log(res)
    //in ra Welcome to GDSC-HUST!
)
```

Trong ví dụ trên chúng ta có thể thấy `async` được đặt trước một hàm thông thường để biến thành một hàm bất đồng bộ, giá trị trả về là một Promise nên chúng ta hoàn toàn có thể gọi hàm và xử lý Promise với `.then()` để lấy ra kết quả.

### 2. Await

**Await** sẽ tạm dừng việc thực hiện các hàm async

- Khi đặt trước một Promise, await sẽ khiến các đoạn code còn lại đợi đến khi Promise kết thúc và trả về kết quả.
- Await chỉ làm việc với Promises, nó không hoạt động với callbacks.
- Cho đến phiên bản ES2021, await chỉ được sử dụng bên trong các hàm async. Ở phiên bản ES2022, JavaScript đã mang đến người dùng khái niệm ***top-level async/await*** giúp sử dụng await một cách linh hoạt hơn.

Đễ dễ hình dung, trước khi có async/await chúng ta sẽ xử lý các đoạn code bất đồng bộ với Promises, bây giờ chúng ta sẽ xử lý các đoạn code đó trong hàm async. Sau đây, mình sẽ ví dụ về việc lấy dữ liệu với 2 cách khác nhau: cách thứ 1 với Promises, và cách thứ 2 với Async / Await.

```javascript
// cách 1:
function getJSON() {
  // To make the function blocking we manually create a Promise.
  return new Promise(function (resolve) {
    fetch("https://dummyjson.com/products").then(function (res) {
      // The data from the request is available in a .then block
      // We return the result using resolve.
      resolve(res.json());
    });
  });
}
// cách 2:
// Async/Await approach

// The async keyword will automatically create a new Promise and return it.
async function getJSONAsync() {
  // The await keyword saves us from having to write a .then() block.
  let res = await fetch("https://dummyjson.com/products");

  // The result of fetch request is available in the res variable.
  // We return it just like in a regular synchronous function.
  return res.json();
}
```

Hai hàm trên đều thực hiện fetch dữ liệu với api https://dummyjson.com/products, sau đó trả về một Promise với dữ liệu đã được xử lý. Tuy nhiên, chúng ta có thể thấy cách tiếp cận với Async/Await ngắn hơn và dễ đọc hơn.

Vì giá trị trả về là một Promise nên chúng ta có thể xử lý tiếp như sau:

```javascript
getJSONAsync().then( function(result) {
	// Do something with result.
});
```

## Xử lý lỗi trong Async/Await

Khi xử lý bất đồng bộ, đôi lúc chúng ta sẽ gặp các lỗi không mong muốn, Async/Await cho phép chúng ta sử dụng câu lệnh try/catch để bắt các lỗi. Chúng ta chỉ cần để các await call của chúng ta vào trong khối try/catch, mệnh đề catch sẽ xử lý các lỗi có thể xảy ra bên trong mệnh đề try:

```javascript
async function doSomethingAsync(){
	try {
		// This async call may fail.
		let result = await someAsyncCall();
	}
	catch(error) {
		// If it does we will catch the error here.
	}  
}
```

Trong một vài trường hơp, chúng ta có thể bắt các lỗi khi đang chạy async function. Bởi vì hàm async trả về một Promise, chúng ta chỉ cần thêm `.catch()` để xử lý sau khi gọi hàm.

```javascript
// Async function without a try/catch block.
async function doSomethingAsync(){
    // This async call may fail.
    let result = await someAsyncCall();
    return result;  
}

// We catch the error upon calling the function.
doSomethingAsync().
    .then(successHandler)
    .catch(errorHandler);
```

Bạn nên quen thuộc với một trong hai cách xử lý lỗi và tuân theo nó. Đôi khi sử dụng cả `try/catch` và `.catch()` sẽ dẫn đến những lỗi không mong muốn.

## Tạm kết

Chúng ta vừa đi qua một số khái niệm cơ bản về Async/Await trong JavaScript. Async/Await giúp cho việc xử lý bất đồng bộ trong Js trở nên dễ dàng và ít gặp lỗi hơn. Cảm ơn các bạn đã đọc bài viết, hẹn gặp các bạn ở những bài viết tiếp theo.

Khi nhắc đến xử lý bất đồng bộ trong JavaScript, chắc ai cũng liên tưởng đến một vấn đề của việc sử dụng callback function, đó là **callback hell**, đại khái trông nó sẽ như [thế này](https://images.viblo.asia/2b67c194-4ef8-4879-a44b-410c1b4bddee.png). Qua thời gian, callback bộc lộ nhiều yếu điểm, thời gian hoàn tất tăng lên do các hàm phải "xếp hàng" để chờ nhau thực hiện, cấu trúc code trở nên khá rối và khó bảo trì.

Giới thiệu về Async/Await trong JavaScript

CSS là một ngôn ngữ không thể thiếu trong lập trình web, với những dự án lớn và phức tạp về mặt giao diện, code CSS có thể trở nên dài dòng, phức tạp và khó bảo trì. Chính vì vậy, chúng ta cần đến sự trợ giúp của CSS Preprocessor, và một trong những ngôn ngữ được ưa chuộng nhất là SASS.

## CSS Preprocessor là gì?

CSS Preprocessors là ngôn ngữ tiền xử lý CSS, là một chương trình giúp biên dịch những cú pháp đặc trưng của ngôn ngữ tiền xử lý thành cú pháp CSS thông thường. CSS Preprocessor sẽ có thêm một số tính năng và cách viết giúp bạn tiết kiệm thời gian viết CSS, dễ dàng bảo trì và phát triển CSS hơn. Có rất nhiều loại CSS Preprocessor trong đó bao gồm SASS, Stylus hay LESS.

## Giới thiệu về SASS

SASS là một chương trình tiền xử lý CSS (*CSS preprocessor*). So với CSS thuần thì SASS có thêm một số tính năng như `nesting, mixins, inheritance` và một số thư viện hỗ trợ đi kèm giúp bạn viết CSS nhanh hơn, dễ dàng hơn và đặc biệt là có cú pháp giống một ngôn ngữ lập trình hơn.

Để bắt đầu với SASS, bạn có thể cài đặt package vào dự án với npm:

```bash
npm install sass
```

Sau khi SASS được cài đặt, bạn có thể biên dịch SASS thành CSS bằng câu lệnh `sass`. Câu lệnh này yêu cầu 2 đối số là file nguồn và file đích, tức là file sass để biên dịch và file css nó biên dịch thành. Chẳng hạn, trong folder `styles` mình có 2 file là `input.scss` và `output.css` thì khi chạy `sass input.scss output.css`, chương trình sẽ lấy `input.scss` và biên dịch lại thành `output.css`.

Nhưng mỗi khi có sự thay đổi trong file scss, bạn cần gõ lại lệnh trên để cập nhật thay đổi với file css, thao tác này có thể hơi mất thời gian và dễ quên. Chính vì vậy, chúng ta có thể bổ sung thêm --watch flag vào câu lệnh để lắng nghe sự thay đổi, mỗi lần file scss được thay đổi và lưu lại, tự động SASS sẽ biên dịch lại file css.

```bash
sass --watch input.scss output.css
```

> 💡 **Fun fact:** SASS có hai cú pháp! Cú pháp thứ nhất là SCSS (.scss) được sử dụng phổ biến hơn. Vì nó như một phiên bản nâng cấp của CSS, mọi cú pháp hợp lệ trong CSS đều hợp lệ trong SCSS. Cú pháp thụt lề (.sass) được sử dụng ít hơn: nó sử dụng thụt lề thay vì dấu ngoặc nhọn `{}` để bao các câu lệnh và dấu xuống dòng thay cho chấm phẩy `;` để phân tách chúng. Các ví dụ trong bài viết này mình sẽ dùng cú pháp SCSS cho quen thuộc và dễ làm quen hơn.
>

## Các tính năng cơ bản trong SASS

### Variables

Trong file scss, chúng ta có thể đặt biến và sử dụng lại biến nhiều lần trong file. Điều này rất hữu dụng, vì đôi khi có nhiều nơi bạn muốn dùng chung một style hoặc muốn thay đổi style nhiều nơi một lúc thì bạn chỉ cần thay đổi giá trị của biến. Biến có thể chứa giá trị của `colors`, các `font style` hay nhiều giá trị CSS khác mà bạn muốn sử dụng lại nhiều lần. Để sử dụng biến, bạn thêm `$` trước tên biến và khai báo giá trị cho nó:

```scss
$font-stack: Helvetica, sans-serif;
$primary-color: #333;

body {
  font: 100% $font-stack;
  color: $primary-color;
}
```

### Nesting

Khi viết HTML, bạn có thể thấy rằng cấu trúc code được tổ chức một cách rõ ràng, mạch lạc, các thành phần được phân cấp và lồng vào nhau. CSS được tạo ra để đi cùng với HTML, các thành phần trong CSS cũng đại diện cho các thành phần trong trang HTML tương ứng. Chính vì vậy, SASS cho phép người dùng lồng các CSS selectors lại với nhau để nó có cấu trúc rõ ràng và được phân cấp như HTML.

```scss
// input.scss
nav {
  ul {
    margin: 0;
    padding: 0;
    list-style: none;
  }

  li { display: inline-block; }

  a {
    display: block;
    padding: 6px 12px;
    text-decoration: none;
  }
}
```

```css
/* output.css */
nav ul {
  margin: 0;
  padding: 0;
  list-style: none;
}
nav li {
  display: inline-block;
}
nav a {
  display: block;
  padding: 6px 12px;
  text-decoration: none;
}
```

Các bạn có thể thấy `ul`, `li` và `a` selectors được lồng vào trong nav selector. Điều này giúp tổ chức lại code CSS và khiến nó dễ đọc hơn. Nhưng bạn cũng cần lưu ý rằng, việc lạm dụng quy tắc lồng nhau có thể dẫn đến CSS trở nên thừa điều kiện và sẽ khó bảo trì sau này.

### Modules

SASS hỗ trợ modules, bạn có thể tách nhỏ các file scss và kết hợp lại trong một file với cú pháp `@use`. Các file thành phần được đặt tên với kí tự gạch dưới đằng trước (ví dụ `_partial.scss`), điều này đảm bảo SASS biết rằng các file này là thành phần nhỏ và không cần biên dịch ra CSS tương ứng. Ví dụ với modules:

```scss
// _base.scss
$font-stack: Helvetica, sans-serif;
$primary-color: #333;

body {
  font: 100% $font-stack;
  color: $primary-color;
}
```

```scss
// styles.scss
@use 'base';

.inverse {
  background-color: base.$primary-color;
  color: white;
}
```

Như ví dụ trên ta có thể thấy modules không chỉ thêm các styles từ file `_base.scss` vào file `styles.scss` mà còn thêm các biến, chúng ta có thể sử dụng biến bằng tên file (`base.$primary-color`).

> ❗ **Lưu ý:** Chúng ta sử dụng `@use '[tên file]'`, tên file không có dấu gạch chân đằng trước và không cần thêm đuôi file (.scss). Sass sẽ biết điều đấy và thực hiện cho chúng ta.

### Mixins

Như mình đã nói ở trên, Sass cho phép bạn viết CSS giống một ngôn ngữ lập trình hơn và Mixins là một tính năng thể hiện điều đấy. Mixins cho phép bạn tạo một nhóm các câu lệnh CSS và sử dụng nó ở mọi nơi như một biến vậy. Tính chất này khiến mình cảm thấy nó giống một hàm và bạn cũng hoàn toàn có thể truyền tham số vào Mixins. Đây là ví dụ về mixin theme:

```scss
// input.scss
@mixin theme($color, $background) {
  background: $background;
  color: $color;
}

.info {
  @include theme(#fff, blue);
}
.warning {
  @include theme(#000, yellow);
}
.success {
  @include theme(#fff, green);
}
```

```css
/* output.css */
.info {
  background: blue;
  color: #fff;
}

.warning {
  background: yellow;
  color: #000;
}

.success {
  background: green;
  color: #fff;
}
```

Để khai báo một mixin, bạn sử dụng cú pháp `@mixin` và đặt tên cho nó, như mình đặt tên cho mixin ví dụ trên là `theme`. Bạn cũng có thể truyền vào các tham số ở trong dấu ngoặc đơn, ở trên là `$background` và `$color`. Cuối cùng, bạn dùng cú pháp `@include` theo sau là tên mixin và các đối số ở trong thành phần bất kì để sử dụng mixin đã tạo.

### Extend/Inheritance

Trong Sass, một CSS selector có thể kế thừa styles từ một CSS selector khác nhờ sử dụng cú pháp `@extend`.

```scss
// input.scss
.btn {
    border-radius: 1rem;
    border: none;
    color: #fff;
}

.success {
    @extend .btn;
    background: green;
}

.danger {
    @extend .btn;
    background: red;
}
```

```css
/* output.css */
.btn, .success, .danger {
    border-radius: 1rem;
    border: none;
    color: #fff;
}

.success {
    background: green;
}

.danger {
    background: red;
}
```

Trong ví dụ trên, khi biên dịch ra file `output.css`, ta có thể thấy class `.success` và `.danger` đều có các thuộc tính CSS giống class `.btn` và thêm các thuộc tính đặc trưng của riêng nó. Tính năng này giúp bạn có thể hạn chế việc thêm nhiều class vào một thẻ HTML.

### Operators

Với Sass bạn có thể dễ dàng thực hiện tính toán trong CSS, Sass hỗ trợ các toán tử cơ bản như `+, -, *, math.div() và %`. Trong ví dụ dưới, mình sẽ thực hiện tính toán cơ bản chiều rộng của 2 phần tử trong 1 thẻ cha.

```scss
@use "sass:math";

.container {
  display: flex;
}

.item-1 {
  width: math.div(600px, 960px) * 100%;
}

.item-2 {
  width: math.div(300px, 960px) * 100%;
  margin-left: auto;
}
```

## Tạm kết

Qua bài viết trên, các bạn có thể thấy Sass là một trình tiền xử lý CSS vô cùng mạnh mẽ, nó không chỉ giúp bạn tiết kiệm thời gian khi viết CSS mà còn cấu trúc lại code rõ ràng, mạch lạc, trở nên dễ đọc và dễ bảo trì. Những tính năng mình nói đến bên trên mới chỉ là một phần ưu điểm của Sass hay rất nhiều CSS Preprocessors khác, các bạn có thể tìm hiểu nhiều hơn những tính năng khác trên trang web của [Sass](https://sass-lang.com/) hoặc mình sẽ bàn luận sâu hơn trong những bài viết khác nhé. Cảm ơn các bạn đã theo dõi.



CSS là một ngôn ngữ không thể thiếu trong lập trình web, với những dự án lớn và phức tạp về mặt giao diện, code CSS có thể trở nên dài dòng, phức tạp và khó bảo trì. Chính vì vậy, chúng ta cần đến sự trợ giúp của CSS Preprocessor, và một trong những ngôn ngữ được ưa chuộng nhất là SASS.

👨‍💻 Coding Posts

Tags