前兩篇分享了 Autocomplete 的實作方式及開發細節，算是少數大家迴響比較多的文章 XDD，下面就來整理一下大家的迴響好了。
---
## 1. 減少傳輸量可以使用 msgpack
小編有聽過 msgpack 但還沒實際了解這是如何運作的。剛查了一下資料 (https://msgpack.org)，說是比 JSON 更省資料大小，基本上聽過的語言都有支援。
在前公司也用過 Avro 這類的格式，主打的也是省資料大小。但現在應該還不會考慮改用這類要另外做 serialize 的格式。
主要是基於後端是以 Node.js 為主開發，JSON 已經是原生支援，再引入一種資料格式會增加前後端維護的複雜度。另外就是開發人力，新創小公司要儘量減少工作，目前可以順暢運作就好，還有其他更重要的事要做，等之後用量大了再改也不遲。
---
## 2. 減少傳輸量可以使用 HTTP server 的壓縮機制
這真的是忽略了，忘了 expressjs 只是一套 web framework，在上面對資料做壓縮其實會影響到效率。讓如 nginx 之類的 HTTP server 做壓縮應該才是更好的作法。
不過因為現在的 infra 是建在 heroku 上面，heroku 並沒有原生 nginx 的支援。等量大撐不住的時候，倒是可以優先考慮使用 heroku 的 buildpack 把 nginx 架上去試試 (https://github.com/heroku/heroku-buildpack-nginx)。
另外也有提到用 CDN 做動態壓縮，這就真的沒做過了，也是可以研究的方向之一。
---
## 3. 減少使用者打 server 的次數，加上 debounce time
這大家都主推使用 debounce 方式，前端沒玩很深的小編第一次碰到這個名詞是高職的時候。記得那時上課在教 8051，老師說按按鈕時要加上 15 - 20ms 的 debounce time，避免重複送外部中斷。小編對單晶片實在不在行，但大概記得是這個意思。
剛查了一下資料 (https://css-tricks.com/debouncing-throttling-explained-examples)，前端的 debounce time 大概也是類似的意思。在輸入文字後，會 delay n 秒再送出，若是在 n 秒內又有打其他內容的時候，就把之前的 request 從 queue 裡面丟棄，只關注最後一次的 request 就好。
這個應該也是有效減少 request 量的作法了。
---
## 4. 減少使用者打 request 的次數，將已經送出的 request 取消掉
這也是一個不錯的作法，若 A request 已經送出去，但還沒回 response 時又送了 B request 的話，此時可以把 A request 取消。
但要注意就是 A request 目前正在執行的步驟是去 DB 拿資料，或是在 server 本身處理一些基本計算。之前在使用 Java (grizzly + jersey) 開發的時候，若有這種情況發生會常在 log 裡面看到 IOException。
原因是 server 已經準備好資料要回傳給 client，但發現 A request 已經取消，不知道要怎麼回傳時就會發生這個狀況。但也有可能是小編自己沒控制好收發的關係啦 XD
---
關於 Autocomplete 的三篇大概就到這篇為止啦，等上線之後做了哪些調整再來分享給大家知道一下。
#funliday #autocomplete #msgpack #debounce #nginx
infra意思 在 Re: [請益] 想請問infra和could engineer未來的發展- 看板MIS 的推薦與評價
※ 引述《breakfastone (我愛吃早餐)》之銘言：
: 本身有aws solution architect associate 的證照
: 最近在思考一個問題 走infra和cloud
: 未來的發展有什麼不一樣
你都有證照了, 還走infra幹什麼?
待遇 AWS >>> Infra
工時 AWS > Infra
被取代性 AWS <<<<<<<<<<<<< Infra
簡單地講,Infra 是屬於花錢的support,AWS屬於賺錢的業務,薪資跟發展自然差很多
舉個例子, Infra 的 MySQL 跟 AWS MySQL 做 HA 的難易度差多少?
Infra 你就是要裝DRDB或是cluster, 裝個PCS就快死人了, 還要oncall
AWS 無腦 RDS 就解決了, 回家爽爽睡
再舉個例子,資料科學家說要1000台機器算ML,時間1小時,AWS便宜又好用,Infra試試看?
現在會架主機service根本沒鳥用,都是花錢的玩意,老闆要的是Solution來賺錢,
馬上上線,能動態擴充,能全球服務不中斷,隨時可以監控,這些只有AWS能給
當然拉,如果是中華之類的大公司,有自己的機房建設,一次丟個1000萬買機器不手軟,
那就是另外一個故事了
當然唯一例外的是工時,因為全球營運的公司24H都在服務,意思就是隨時要處理問題
當然這也是看公司拉, 還有主管的sense有沒有到位
大概是這樣
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.241.234.239
※ 文章網址: https://www.ptt.cc/bbs/MIS/M.1536251874.A.503.html
試想業務告訴你,他的客戶營業範圍想從亞洲延伸到歐洲
用AWS你只要滑鼠點一點,AP裝一裝,三天就上線,有問題案子停了隨時可以撤掉
自建機房搞個一個月起跳,還要在當地養人維護,有問題案子停了投了那麼多錢怎麼辦?
※ 編輯: ddoll288 (111.241.233.66), 09/07/2018 08:15:09
... <看更多>