這一系列文總共有三篇，這是最後一篇。

Funliday 重磅推出新的 prerender 套件 pppr！這是一個 zero config 的 express middleware，只要 npm install pppr，然後在 app.js 裡面加一行 app.use(pppr()) 就可以直接拿來用了。

---

原本在使用 prerender.io 這個套件有時候會出現 504 timeout 的問題，後來發現這個套件用的是比較底層的 API (Chrome DevTools Protocol, CDP)，研究它的原始碼後發現 render HTML 的 timeout 判斷上有些怪怪的，本來想試著去改這塊，但對 CDP 不熟，所以用 puppeteer 重寫一套 prerender service，pppr 也就應運而生。

簡單先解釋一下，puppeteer 是基於 CDP 封裝後成為比較容易使用的 API。因為 client side rendering (CSR) 的流行，所以現在要做網路爬蟲的話，愈來愈多會選擇用 puppeteer 來處理。這裡來分享一下在開發 pppr 的時候，有哪些東西要注意的。

1. 把 URL 放到像是 50 人的 LINE 熱門群組，prerender 會遭到大量的 request，因為每個使用者接收到這個訊息之後，因為要顯示 og data，所以就會去打一次 prerender。這裡姑且先稱之為 OG-DDoS 好了 XD，所以一定要做 cache，讓第一個 request 把 HTML 產生出來之後就放到 cache 裡面。然後可以用 LRU cache 來處理，因為這類 URL 都是短時間會被大量使用，之後就很少被用了，用 LRU cache 剛剛好。

1-1. 其實這一段實作還有一些問題，如果在第一個 request 還沒產生出 HTML 之前，第二個同樣 request 就進來了，這樣子 cache 可以說是根本沒作用，還要再找時間來處理 lock 機制才行。

2. 每一個 request 要新開一個 page 才行，如果沒有每個 request 都開新 page 的話，會造成 A request 還沒處理完，B request 就用同一個 page 做 render，這樣子 A request 就會 504 timeout 了。所以一定要記得每個 request 都要新開 page。

3. 因為 headless chrome 的 user agent 就叫做 HeadlessChrome，為了避免在 render 的時候會出現意料外的狀況，保險一點還是把 HeadlessChrome 改成 Chrome 會比較好。

4. 注意 redirect。因為 expressjs 跟 puppeter 是兩個不同的 context，對於 redirection 來說，expressjs 會回傳 3xx 系列的狀態碼，但 puppeteer 則會直接執行完成。所以把 puppeteer 放在 expressjs 裡面執行的話，必須要處理 redirect chain，讓 expressjs 能回給 client 正確的狀態碼才行。

5. pppr 因為是發想自 prerender.io，所以 interface 也一樣是 /render?url=https://example.com。 但有時候原始的 url 後面會包含 query string，所以 expressjs 要用 URLSearchParams 另外做些處理，才能取得完整的 url。

開發 pppr 基本要注意的事項大概就這樣，總之記得給星，有任何問題歡迎發 issue 跟 pr 喔！

#pppr #prerender #funliday

前一篇 (https://www.facebook.com/kewang.information/posts/2241503749459320) 提到了 Autocomplete 的實作方式，但仍然有許多可以調整的地方，像是如何加大 throughput、帶額外資料...等，下面就來分享一下小編的作法。

---

## 1. 減少傳輸量

因為 Autocomplete 的操作行為是使用者每打一個字，就要傳給 server，server 再回傳使用者一些 candidate。所以減少傳輸量是最先要處理的事情，要不然資料量太大傳輸慢會影響前端使用體驗。最簡單的作法就是改變原本回傳的 JSON 格式，如下所示：

### 調整前

[
{"id": 123, "candidate": "taipei"},
{"id": 456, "candidate": "taiwan"},
{"id": 789, "candidate": "tall"}
]

### 調整後

["123%taipei","456%taiwan","789%tall"]

前端拿到資料後自己再用 split 的方式分割字串，實測下來大概可以減少 40% 的資料量。

---

## 2. 減少傳輸量

沒錯！第二點也是減少傳輸量，將準備要回傳的資料用 gzip 壓縮後再回傳。

以 expressjs 本身建議的 compression 套件來說，實測下來發揮不了什麼作用。因為 compression 套件預設為資料量大於 1kb 才會做壓縮，而目前的資料已經是小於 1kb 了，所以沒做任何壓縮就直接回傳。

另外還發現加了 compression 套件之後，以目前開的 heroku 機器來說，回應時間會加上 5-10ms 左右。不過現在服務還沒上線，沒有使用量都不準，等上線之後再來觀察看看好了。

---

## 3. 減少使用者打 server 的次數

前端可以在輸入一個字元的時候不要送 request 給 server，因為經驗法則，使用者應該至少會打兩個字元之後，Autocomplete 回應給使用者 candidate，這樣對 UX 上應該會比較好吧 (小編不專業分析 XD)。不止可以降低 server 的 loading，也可以減少存入 Redis 的資料量。

但這會牽涉到 CJK 與 non-CJK 的處理方式，這就還要再看看如何處理比較好。

---

## 4. 減少使用者打 server 的次數

沒錯！又是減少次數。client 可以在 server 回傳資料的時候，將資料暫存在 client 的記憶體內。因為常會有輸入相同文字的時候，這時就可以直接從 client 的記憶體取出資料，就不用打到 server 了。

但這個使用方式比較不好處理，需視情境而定。若是 Redis 的資料常常在變動，那這個方式會造成取不回最新的資料。或許可以在 client 放個 LRU cache 來做處理。

---

## 5. 減少使用者打 server 的次數

又是我 XDDD！這次是要 server 幫忙，當 client 重複輸入相同 keyword 時，client 會帶 If-None-Match 的 header 給 server，server 會檢查這串值是否已經有打過了，如果打過就回 client 304，表示資料沒變動，可以直接用 client 本身的資料。

這在之前的 JCConf 有分享 (https://www.facebook.com/kewang.information/posts/2192127034396992) 過，大家可以回去翻一下。

---

## 6. 減少 Redis 的資料量

西方國家所用的拉丁字母除了大家常用的 26 個英文字母外，也常會有一些包括重音之類的字母。像是 a 及 á 之類的，這個在搜尋的時候不會太影響，JavaScript 可以利用 String.normalize('NFD') 把 á 轉換成 aˊ，最後再將 ˊ 取代為空字串 (https://stackoverflow.com/a/37511463/939212)，Redis 裡面只要存 a 就好，這樣可以節省不少資料量。

當然還有將大寫轉為小寫、trim 掉頭尾空白這幾種做法，也都可以省下不少資料量。

至於 CJK 的話，再說吧 XDDD

---

## 7. 存入 metadata

如果這個 Autocomplete 只是單純選擇 candidate 之後做搜尋，那可以不用存 metadata 進去。但有些功能其實是要把 candidate 回傳給 client 時，也帶一些 metadata 給 client 做其他運用，最常見的應該就是帶 id 這類 metadata 了。

最簡單的作法就是在存入 candidate 的時候，直接把要存的 metadata 帶在字尾，如下所示：

1. t
2. ta
3. tai
4. taiw
5. taiwa
6. taiwan
7. taiwan*123

把 123 放在 taiwan 後面，在取出 candidate 的時候再利用 split 的方式把 taiwan 跟 123 分別取出就可以了。

---

總結上面的幾種方式，目前小編這裡用到了 1, 2, 5, 6, 7 共五種，效果還不錯，就等上線再來看看實戰結果囉。

#funliday #autocomplete #redis #javascript #nodejs