DEV Community: Jian Lin Huang

Parallelizing jobs in Node.js

Jian Lin Huang — Tue, 20 Jul 2021 05:29:10 +0000

When writing applications, we usually face to the issue that we need to do lots of asynchronous jobs parallelly, for example, assume that we have 1000 files to download, and each file doesn't depend on the others, so we can download it parallelly. We cannot send 1000 requests simultaneously, therefore, we need to run the number of jobs under an ideal one. For example, we can limit the max number of running jobs and put the pending jobs into a queue. After finishing the job, then pop the pending job from the queue and start it afterward.

In this article, I am going to show you how to use Node.js to implement it which I mentioned above.

Static number of jobs

In the first part, I will show you the "Parallelization with a static number of jobs", which means the number of jobs is pre-defined, and the new jobs will never be pushed to the job queue until the program is terminated.

First of all, we are going to define the job we are going to run, to avoid too complicated code to understand, I will use Promise and setTimeout to simulate the asynchronous job:

const buildJob = (jobId, executionTime) => {
    return () => {
        console.log(`[Job ${jobId}] Start.`)
        return new Promise(resolve => {
            setTimeout(() => {
                console.log(`[Job ${jobId}] End, it takes ${executionTime} ms.`)
                resolve();
            }, executionTime);
        })
    }
}

// we expect that each job should output the message like this:
// [Job 1] Start.
// [Job 1] End, it takes 2512 ms.

In the five lines of code above, the buildJob() function will return a function that returns a Promise after calling it. and then we can use this function to build a series of jobs.

const randomExecutionTimes = (new Array(10))
    .fill()
    .map(() => Math.floor(Math.random() * 2000 + 1000))
const jobs = randomExecutionTimes
    .map((executionTime, index) => buildJob(index, executionTime))

Now, we have got 10 jobs which have totally random execution time from 1000ms to 3000ms, let's make them run parallelly.

const jobsQueue = jobs.map(job => job);

First of all, we need to build a new array named jobsQueue because we must keep the jobs unchanged, and we see the start of this newly created array as tail, and the end of the array as head, so only we need to do is pop() the last element of the array and call the job functions.

Now, we gonna write a function call startJob() that starts a job at the head of the queue.

function startJob() {
    const job = jobsQueue.pop();
    // start another job after finishing the previous one.
    if(job) return job.then(startJob)
}

Then, let's start running the job.

// We use the variable to define the max number of jobs
const MAX_PARALLEL_NUMBER = 3;
// Then use the for loop to start 
for(let i = 0; i < MAX_PARALLEL_NUMBER; i ++) {
    startJob();
}

Finally, let's combine all parts together.

const buildJob = (jobId, executionTime) => {
    return () => {
        console.log(`[Job ${jobId}] Start.`)
        return new Promise(resolve => {
            setTimeout(() => {
                console.log(`[Job ${jobId}] End, it takes ${executionTime} ms.`)
                resolve();
            }, executionTime);
        })
    }
}

const randomExecutionTimes = (new Array(10))
    .fill()
    .map(() => Math.floor(Math.random() * 2000 + 1000))
const jobs = randomExecutionTimes
    .map((executionTime, index) => buildJob(index, executionTime))

const jobsQueue = jobs.map(job => job);

function startJob() {
    const job = jobsQueue.pop();
    if(job) return job.then(startJob)
}

const MAX_PARALLEL_NUMBER = 3;
for(let i = 0; i < MAX_PARALLEL_NUMBER; i ++) {
    startJob();
}

Ok, done. Let's run the program.

[Job 9] Start.
[Job 8] Start.
[Job 7] Start.
[Job 8] End, it takes 1308 ms.
[Job 6] Start.
[Job 7] End, it takes 1566 ms.
[Job 5] Start.
[Job 9] End, it takes 1806 ms.
[Job 4] Start.
[Job 5] End, it takes 1324 ms.
[Job 3] Start.
[Job 6] End, it takes 1885 ms.
[Job 2] Start.
[Job 4] End, it takes 2289 ms.
[Job 1] Start.
[Job 2] End, it takes 2275 ms.
[Job 0] Start.
[Job 1] End, it takes 1449 ms.
[Job 3] End, it takes 2849 ms.
[Job 0] End, it takes 1981 ms.

By the way, let's make a little change to see how long it takes to finish this program.

const MAX_PARALLEL_NUMBER = 3;
// save the time when starting
const startTime = Date.now();
const executors = [];
for(let i = 0; i < MAX_PARALLEL_NUMBER; i ++) {
    executors.push(startJob());
}
// wait for all jobs be done.
Promise.all(executors).then(() => {
    const endTime = Date.now();
    console.log(`All jobs take ${endTime - startTime} ms running.`)
})

And this is the output of this change:

[Job 9] Start.
[Job 8] Start.
[Job 7] Start.
[Job 8] End, it takes 1308 ms.
[Job 6] Start.
[Job 7] End, it takes 1566 ms.
[Job 5] Start.
[Job 9] End, it takes 1806 ms.
[Job 4] Start.
[Job 5] End, it takes 1324 ms.
[Job 3] Start.
[Job 6] End, it takes 1885 ms.
[Job 2] Start.
[Job 4] End, it takes 2289 ms.
[Job 1] Start.
[Job 2] End, it takes 2275 ms.
[Job 0] Start.
[Job 1] End, it takes 1449 ms.
[Job 3] End, it takes 2849 ms.
[Job 0] End, it takes 1981 ms.
All jobs take 7476 ms running.

Pretty cool, we make the jobs run parallelly. I make a chart to show how the jobs are done, when there are only three jobs run simultaneously. This graph shows that all jobs can be done at 7225ms in theory, which almost equals to the result: 7476ms.

Dynamic number of jobs

The first part is just an example, it shares the concept of parallelizing jobs, however, in some production scenery, we face to more complex conditional than this, isn't it? In the second part, we are going to move further, I'll show you the "Parallelization with dynamic number of jobs", which means the jobs will be pushed to queue during the program runs.

We can not ensure when jobs will be pushed to the queue is the main difference between dynamic queue and static one. In the previous section, we start the next job from the previous job after finishing execution. However, in the dynamic queue, the jobs could be pushed when there are only 1 or 2 jobs are still running.

The graph shows that if we only use the method provided in the first section. When the jobs are pushed to the queue at the timing which is marked in the graph, it has only two parallel jobs left, because after Job3 is done, startJob() will be called afterward but get nothing to run.

Let's make some changes from the code written in the first section. First, we gonna implement a function called addJob().

function addJob(job) {
    jobsQueue.unshift(job);
    return startJob();
}

This function is very simple, the most important part is calling startJob() after adding a job to the queue. The purpose that calling startJob() afterward is to make sure that every job has its startJob(). To put it differently, if there is any job in the queue, then startJob() call by the previous job, otherwise, the startJob() is called after adding a job to the queue.

Now, we are going to modify the startJob() function, because startJob() will to run the job after being called.

let concurrentJobsCount = 0;
function startJob() {
    if(concurrentJobsCount >= MAX_PARALLEL_NUMBER) {
        const job = jobsQueue.pop();
        if(job) {
            concurrentJobsCount ++;
            return job.then(startJob).finally(() => {concurrentJobsCount --})
        }
    }
}

We have almost done. Because this is a single-process and single-thread application, so we don't need to see concurrenctJobsCount as a critical section variable, so just use it directly to count how many jobs are running.

In the end, left write a simple script to add jobs to the queue when running.

// because we have 10 jobs already, so jobId start from 11.
let jobId = 11;

// this function will create a job and append to the queue every 2000ms.
function createRuntimeJob() {
    setTimeout(() => {
        const job = buildJob(jobId ++, Math.floor(Math.random() * 2000 + 1000));        
        addJob(job);
        createRuntimeJob();
    }, 2000)
}

createRuntimeJob();

Let's combine the code again:

const buildJob = (jobId, executionTime) => {
    return () => {
        console.log(`[Job ${jobId}] Start.`)
        return new Promise(resolve => {
            setTimeout(() => {
                console.log(`[Job ${jobId}] End, it takes ${executionTime} ms.`)
                resolve();
            }, executionTime);
        })
    }
}

const randomExecutionTimes = (new Array(10))
    .fill()
    .map(() => Math.floor(Math.random() * 2000 + 1000))
const jobs = randomExecutionTimes
    .map((executionTime, index) => buildJob(index, executionTime))

const jobsQueue = jobs.map(job => job);

const MAX_PARALLEL_NUMBER = 3;
let concurrentJobsCount = 0;
function startJob() {
    if(concurrentJobsCount < MAX_PARALLEL_NUMBER) {
        const job = jobsQueue.pop();
        if(job) {
            concurrentJobsCount ++;
            return job().then(startJob).finally(() => {concurrentJobsCount --})
        }
    }
}

for(let i = 0; i < MAX_PARALLEL_NUMBER; i ++) {
    startJob();
}

function addJob(job) {
    jobsQueue.unshift(job);
    return startJob();
}

let jobId = 11;
function createRuntimeJob() {
    setTimeout(() => {
            const job = buildJob(jobId ++, Math.floor(Math.random() * 2000 + 1000));        
            addJob(job);
            createRuntimeJob();
    }, 2000)
}

createRuntimeJob();

We make all jobs run parallelly and it looks good! After deleting the code that do job generation, we have few lines of code left:

// jobs varaiable is defined by yourself.
const jobsQueue = jobs.map(job => job);

let concurrentJobsCount = 0;
function startJob() {
    if(concurrentJobsCount < MAX_PARALLEL_NUMBER) {
        const job = jobsQueue.pop();
        if(job) {
            concurrentJobsCount ++;
            return job().then(startJob).finally(() => {concurrentJobsCount --})
        }
    }
}

const MAX_PARALLEL_NUMBER = 3;
for(let i = 0; i < MAX_PARALLEL_NUMBER; i ++) {
    startJob();
}

function addJob(job) {
    jobsQueue.unshift(job);
    return startJob();
}

// pretty simple, isn't it?

Thank for reading

In this article, we discuss parallelizing asynchronous jobs and make the number of simultaneously running jobs be limited under a specified number. However, the methods mentioned in this article are not suitable for CPU-intensive jobs, because CPU-intensive jobs will occupy CPU and make thread be blocked. Maybe in the next article, I will share my solution to handle CPU-intensive parallelly via Worker Thread.

用 Cloudflare Worker 來佈署靜態網頁

Jian Lin Huang — Thu, 23 Jul 2020 00:54:17 +0000

得益於 Cloudflare 在全球超過 200 多個節點，我們可以很輕易的將我們的應用程式快速的推向 Cloudflare 的全球網路邊緣，這可以讓我們的應用程式的 Response Time 變得更低，如一個以 SPA 技術開發的 Web Application 就可以很輕易的佈署至 Cloudflare Worker。

基礎環境建立

首先我們需要安裝用於佈署 Worker 的工具：@cloudflare/wrangler，我們可以透過 npm 來安裝這個工具：

~$ sudo npm install -g @cloudflare/wrangler

安裝完畢之後我們進入 Cloudflare 的網站，在右欄的部份找到這個區塊，並按下 "取得您的 API Token"。

進入頁面之後點選 API Token 的 Tab 並按下"建立 Token"

並且在建立的頁面中點選 "編輯 Cloudflare Worker"，並進入頁面

在權限的區塊，這裡選定的區塊是 "編輯 cloudflare worker 必要的權限"，因此若沒有其他的需求，就不用額外調整權限區塊。在帳戶資源部份請至少選擇 "包含" 自己的帳戶。區域資源的部份可以選擇特定區域，以免不小心異動其他網域的內容，如果沒有這類的疑慮，也可以直接選擇包含所有區域。

確定之後就會跳出摘要頁面，確認資料無誤之後就可以按下"建立 Token"：

取得上述的 Token 之後我們就可以回到 Terminal，輸入指令後按照要求將 API Token 貼上

~$ wrangler config

To find your API Token, go to https://dash.cloudflare.com/profile/api-tokens
and create it using the "Edit Cloudflare Workers" template.

If you are trying to use your Global API Key instead of an API Token
(Not Recommended), run `wrangler config --api-key`.
Enter API Token: 
B4jLkMW933P3P5tsDOqLbKZLi9UMLPEkH8xQdOI7
 Validating credentials...
 Successfully configured. You can find your configuration file at: /home/floatflower/.wrangler/config/default.toml

看到 Successfully configured 之後就代表環境已經設定好囉。

佈署網站

建立一個靜態網頁模板

~$ wrangler generate --site mysite

Creating project called `mysite`...
 Done! New project created /home/floatflower/mysite
 You will need to update the following fields in the created wrangler.toml file before continuing:
 You can find your account_id in the right sidebar of your account's Workers page, and zone_id in the right sidebar of a zone's overview tab at https://dash.cloudflare.com
- account_id

~$ cd mysite

接著我們就會拿到這些檔案：

.
├── node_modules
├── package-lock.json
├── public
│   ├── 404.html
│   ├── favicon.ico
│   ├── img
│   │   ├── 200-wrangler-ferris.gif
│   │   └── 404-wrangler-ferris.gif
│   └── index.html
├── workers-site
│   ├── index.js
│   ├── package.json
│   └── package-lock.json
└── wrangler.toml

public 資料夾就是放置靜態網站的資料夾，你可以把你的靜態網頁放在裡面。
worker-site 就是 Cloudflare Worker 的程式碼，你可以在這裡定義自己的 Cloudflare Worker 行為，但是在這裡我們也不用做其他改變，直接用預設的就可以了。

調整 wrangler.toml

我們打開 wrangler.toml 裡面含有這些內容：

# worker 名稱
name = "mysite" 
type = "webpack"
account_id = ""

# 如果選擇 true 的話，Cloudflare 會提供給你一個 .workers.dev 網域的網址，因為我們要提供網域，所以我們將其設為 false。
workers_dev = false
# 如果 workers_dev 是 false 時，這個 route 一定要提供，我這邊示範的網址是 mysite.fres.host。
route = "mysite.fres.host/*"
zone_id = ""

[site]
bucket = "./public"

其中的 account_id 以及 zone_id 我們就會回到剛才取得 API Token 那個區塊：

其中的區域識別碼貼至 zone_id 以及帳戶識別碼貼至 account_id。

佈署上線

接著我們執行佈署的指令

~$ wrangler publish

...

 Built successfully, built project size is 13 KiB.
 Created namespace for Workers Site "__mysite-workers_sites_assets"
 Success
 Uploading site files
 Deployed to the following routes:
mysite.fres.host/* => created

接著我們回到 Cloudflare Worker 的頁面：

就會看到一個 mysite.fres.host/* => mysite，但是還沒結束。我們要進入 DNS 的頁面，新增一個 DNS Record：

DNS Record 的值可以為隨意，因為全部都會被 Cloudflare 攔截起來，所以網域不管指向哪裡都可以，對應完畢之後我們就可以打開瀏覽器並訪問網址，在這裡我的網址是 https://mysite.fres.host 。

就會看到 Cloudflare 的預設頁面，做到這裡最基本的 Cloudflare 佈署就完成了。

番外篇：用 Cloudflare Worker 佈署 History mode 的 Vue SPA Application

首先我們先開啟一個 Vue SPA 的應用程式，並選擇開啟 History Mode，然後我們將剛才產生的 wrangler.toml 以及 worker-site 移到這個 mysite_spa 底下。

~$ vue create mysite_spa

接著在設定之前首先先看一下 Vue.js 官方文件提到當需要佈署 History mode 的應用程式時，所需要做的設定，以 Nginx 做範例：

location / {
    try_files $uri $uri/ /index.html;
}

概念就是先 try-file 看看有沒有路徑對應的文件，如果沒有則遞送 index.html。

更改 wrangler.toml

因為在 Vue Application 中 public 資料夾另有他用，因此我們不能照常將 wrangler.toml 的 bucket 設為 ./public 資料夾，而是要將其改成 ./dist。

# 將 site 區塊的設定改成這樣
[site]
bucket = "./dist"

更改 worker-site/index.js

接著我們要修改 worker-site/index.js 檔案的內容，以符合上述提到的 Nginx 遞送 Vue Application 的邏輯。

我們先打開 worker-site/index.js

import { getAssetFromKV, mapRequestToAsset } from '@cloudflare/kv-asset-handler'

/**
 * The DEBUG flag will do two things that help during development:
 * 1. we will skip caching on the edge, which makes it easier to
 *    debug.
 * 2. we will return an error message on exception in your Response rather
 *    than the default 404.html page.
 */
const DEBUG = false

addEventListener('fetch', event => {
    try {
        event.respondWith(handleEvent(event))
    } catch (e) {
        if (DEBUG) {
            return event.respondWith(
                new Response(e.message || e.toString(), {
                    status: 500,
                }),
            )
        }
        event.respondWith(new Response('Internal Error', { status: 500 }))
    }
})

async function handleEvent(event) {
    const url = new URL(event.request.url)
    let options = {}

    /**
   * You can add custom logic to how we fetch your assets
   * by configuring the function `mapRequestToAsset`
   */
    // options.mapRequestToAsset = handlePrefix(/^\/docs/)

    try {
        if (DEBUG) {
            // customize caching
            options.cacheControl = {
                bypassCache: true,
            }
        }

        const page = await getAssetFromKV(event, options)

        // allow headers to be altered
        const response = new Response(page.body, page)

        response.headers.set('X-XSS-Protection', '1; mode=block')
        response.headers.set('X-Content-Type-Options', 'nosniff')
        response.headers.set('X-Frame-Options', 'DENY')
        response.headers.set('Referrer-Policy', 'unsafe-url')
        response.headers.set('Feature-Policy', 'none')

        return response

    } catch (e) {
        // if an error is thrown try to serve the asset at 404.html
        if (!DEBUG) {
            try {
                let notFoundResponse = await getAssetFromKV(event, {
                    mapRequestToAsset: req => new Request(`${new URL(req.url).origin}/404.html`, req),
                })

                return new Response(notFoundResponse.body, { ...notFoundResponse, status: 404 })
            } catch (e) {}
        }

        return new Response(e.message || e.toString(), { status: 500 })
    }
}

/**
 * Here's one example of how to modify a request to
 * remove a specific prefix, in this case `/docs` from
 * the url. This can be useful if you are deploying to a
 * route on a zone, or if you only want your static content
 * to exist at a specific path.
 */
function handlePrefix(prefix) {
    return request => {
        // compute the default (e.g. / -> index.html)
        let defaultAssetKey = mapRequestToAsset(request)
        let url = new URL(defaultAssetKey.url)

        // strip the prefix from the path for lookup
        url.pathname = url.pathname.replace(prefix, '/')

        // inherit all other props from the default request
        return new Request(url.toString(), defaultAssetKey)
    }
}

程式有點長，不過我們並沒有要修改太多，找到以下這個區塊，這個區塊定義了當應用程式找不到指定檔案的時候就返回 404.html 並將 Http Status Code 設為 404 Not Found。

// if an error is thrown try to serve the asset at 404.html
if (!DEBUG) {
    try {
        let notFoundResponse = await getAssetFromKV(event, {
            mapRequestToAsset: req => new Request(`${new URL(req.url).origin}/404.html`, req),
        })

        return new Response(notFoundResponse.body, { ...notFoundResponse, status: 404 })
    } catch (e) {}
}

因此我們將這段程式修改成這樣：

// if an error is thrown try to serve the asset at 404.html
if (!DEBUG) {
    try {
        let notFoundResponse = await getAssetFromKV(event, {
            mapRequestToAsset: req => new Request(`${new URL(req.url).origin}/index.html`, req),
        })

        return new Response(notFoundResponse.body, { ...notFoundResponse, status: 200 })
    } catch (e) {}
}

這樣就可以在找不到檔案時遞送 index.html 給客戶端了，完成之後我們做一次打包，然後我們透過 wrangler dev 指令打開測試伺服器並訪問 http://localhost:8787 ，來看看設定是否正確。

~$ npm run build
~$ wrangler dev

在 Vue Application 的 Demo 頁面中就可以直接嘗試是否 History Vue Router 可以正常運作：

http://localhost:8787

http://localhost:8787/about

確定無誤之後我們就可以將其佈署至 Cloudflare Worker，最後我們訪問一下佈署的頁面：https://mysite.fres.host

~$ wrangler publish

就可以看到結果頁面：

前端異步 AJAX 請求的重複使用

Jian Lin Huang — Wed, 22 Jul 2020 01:54:19 +0000

在開發前端時，我們非常常使用 AJAX 來異步資料並動態渲染在頁面上，但是在遇到一連串的相同資料都要進行請求時，就有可能對同一個 API Endpoint 發出併發請求，然而，因為這些請求是同時發出，因此 Response 也非常可能是相同的，這樣講可能不夠清楚，直接寫一個簡易的範例來解釋這個情況。

實際範例

首先我們先撰寫一個 API：

https://localhost:3000/api/v1/users/:uuid

這個 API 的回傳值如下：

{
    "name":"Username{uuid}",
    "uuid":"{uuid}"
}

接著開一個 Vue SPA 專案，並且先透過 Axios 寫一個異步請求的函數：

// fetch-user.js

const axios = require('axios');

module.exports = (uuid) => {
    let uri = `http://localhost:3000/users/${uuid}`;
    return new Promise(resolve => {
        axios.get(uri).then(resolve);
    })
};

然後我們在 Vue 專案中新增一個 User Component(User.vue) 來負責渲染並請求資料：

<template>
    <div v-if="init">
        <ul>
            <li>{{user.name}}</li>
            <li>{{user.uuid}}</li>
        </ul>
    </div>
</template>

<script>
    const fetchUser = require('../lib/fetch-user');
    export default {
        name: 'User',
        data: function() {
            return {
                init: false,
                user: null
            }
        },
        props: {
            uuid: String
        },
        async mounted() {
            const response = await fetchUser(this.uuid);
            this.init = true;
            this.user = response.data;
        }
    }
</script>

最後將 user component 放入 App.vue 中：

<template>
    <div id="app">
        <user uuid="user-uuid"></user>
        <user uuid="user-uuid"></user>
        <user uuid="user-uuid"></user>
        <user uuid="user-uuid"></user>
        <user uuid="user-uuid"></user>
        <user uuid="user-uuid"></user>
        <user uuid="user-uuid"></user>
        <user uuid="user-uuid"></user>
        <user uuid="user-uuid"></user>
        <user uuid="user-uuid"></user>
        <user uuid="user-uuid"></user>
        <user uuid="user-uuid"></user>
        <user uuid="user-uuid"></user>
        <user uuid="user-uuid"></user>
        <user uuid="user-uuid"></user>
    </div>
</template>

<script>
import User from './components/User';

export default {
    name: 'App',
    components: {
        User
    }
}
</script>

接著我們看一下顯示結果：

這樣就正確顯示了，然而這裡有一個問題非常直接注意：

我們打開開發者模式就會發現，每個元件向該 API 發出了請求，因此就產生了 10 次的併發請求，但是在這種情況下，實際上我們僅需要讓一個請求出去，另外 9 個元件等待這個請求的 Response 然後複用即可。

改進的方法

接下來將講解要如何實現對於在同一個時間內僅對指定 API 請求一次並複用請求，我們會用到這個元件，這個元件有點類似 Node.js 中的 EventEmitter，主要就是用於收發事件。

https://developer.mozilla.org/zh-TW/docs/Web/API/EventTarget

接著我們改寫 fetchUser() 函數：

const axios = require('axios');

/**
 * 這個 class 是用於儲存 Response Data 的 Event 衍生類
 */
class FetchCompleteEvent extends Event {
    constructor(type, data) {
        super(type);
        this.data = data;
    }
}

// 用於請求成功時使用的事件監聽器
const eventEmitter = new EventTarget();

// 用於請求失敗時使用的事件監聽器
const errorEmitter = new EventTarget();

/**
 * 用於儲存 URI 以及是否當前正在請求的對應，如:
 * http://localhost:8000/users/foo => true 代表已經發出請求，正在等待 Response
 * http://localhost:8000/users/bar => false 代表當前沒有請求在路上
 */

const requestingList = new Map();

module.exports = (uuid) => {

    let uri = `http://localhost:3000/users/${uuid}`;

    return new Promise((resolve, reject) => {

        // 如果沒有紀錄，或者尚未處於請求狀態
        if (!requestingList.has(uri) || !requestingList.get(uri)) {

            // 進入之後立即將請求狀態設為 true
            requestingList.set(uri, true);

            // 請求 URI
            axios.get(uri).then(response => {

                // 完成請求之後將請求狀態設為 false
                requestingList.set(uri, false);

                // 發出一個事件通知來告訴 callback 請求完成了
                eventEmitter.dispatchEvent(new FetchCompleteEvent(uri, response));
                resolve(response);

            }).catch((e) => {

                // 請求失敗也算是請求完成，將請求狀態設為 false
                requestingList.set(uri, false);

                // 發出一個事件通知來告訴 callback 請求失敗了
                errorEmitter.dispatchEvent(new FetchCompleteEvent(uri, e));
                reject(e);

            })
        }
        // 當目前指定的 URI 處於請求狀態，則不做任何事情
        else {

            // 向成功的事件監聽器註冊，當完成之後 resolve()
            eventEmitter.addEventListener(uri, (event) => {
                resolve(event.data);
            });

            // 失敗之後 reject()
            errorEmitter.addEventListener(uri, (event) => {
                reject(event.data);
            })
        }
    });
};

接著我們重新運行前端應用程式並查看結果：

結果與一開始一模一樣，但這時候我們打開開發者模式就會發現：

請求已經被減少到剩下一個了，這是因為所有的元件都重複使用了同一個 Response。透過這種方法將可以大大減少伺服器的負載以及前端的運行時間。

結論

並不是每一種情況下都可以使用這種方式來請求資料，如：每次請求資料都一定會不一樣的 API 就不能使用這種方式進行 API 呼叫，但是像是上述範例中的用戶資料、電商網站中的商品資料或是部落格的文章等，這類能夠確保在極短時間之內資料都相同的 API 就可以使用這種方式來進行呼叫。