剛剛在整理筆記的時候，發現兩年半前還在前公司就應該要發的文章一直躺在筆記裡面，快點整理一下 po 出來。
---
這是第三篇關於 log 的文章，應該也是最後一篇了，這次來聊聊如何讓開發者用 log 了解自己發出的 API 流程是否正確及如何提升效率。
強者小編同事用 python 寫的 log 整理工具，其實就是把 AP 吐出來的一堆多行 debug log，轉成只有 header、url、執行時間的單行 log。所以其實可以把產生出的 API log 再用其他 Linux 指令，即時顯示給開發者看。
---
這麼做的好處不少，對 frontend 來說，可以避免下列問題發生：
1. API 誤用：A 畫面應該是要串 a API，可是卻串到了 b API，又或是串成了 a' API。串成 b 是有點誇張啦，但最近 review 後發現 a' API 倒是比較常出現，像是參數帶錯之類的。
2. 誤解 API 流程：流程應該是串 abc，可是卻串成了 acb。有時候這不是什麼大問題，但在注重流程的 App 上這就很嚴重了。
3. API 狂發：流程應該是串 abc，但卻變成了 abbbcc。這個問題在使用上比較難發現，因為會有這類問題的大都是 GET API，依 RESTful GET API 的 idempotent 特性，無論執行多少次 GET，結果都會是一樣，所以也就更難發現問題了。
---
對 backend 來說的好處也不少：
1. 了解 cache 設計方向：像是剛剛的第 3 點問題，在 frontend 還沒更版前，backend 可以先加上 Cache-Control 機制，把大量的無效 request 從資料庫轉移到 Cache 裡面，當然 frontend 本來就要有這機制才行。
2. 了解每支 API 的效率：開發 API 沒幾個重點，就是流程正確、執行速度快，其中執行速度也是最難處理的一塊。所以了解 API 的處理速度，才有辦法做最佳化。
用這套工具就可以把上面提到的幾個重點一一檢視，也發了十幾個 issue 給 frontend 及 backend，算是 CP 值很高的一個開發。
---
至於技術細節，其實也就下面兩個重點而已：
1. 用 SocketIO 建置一套 WebSocket Server，然後放兩個輸入框，表示要訂閱 (subscribe) 的 log 來源及要監視的 user id
2. 用 tail -f 將 log 即時 pipe 到強者同事寫的 log 整理工具，再用 awk 把需要的欄位輸出，最後將輸出的欄位發送到 WebSocket Server
這個即時顯示 log 的網頁從發想到完成，工時應該只有兩三個小時吧，但發揮的效用可說是非常的大，今天就靠這個網頁開了十幾張單，算是最近小編蠻能說嘴的一項工作了吧 XDDD
* https://www.facebook.com/kewang.information/posts/2058766574399706
* https://www.facebook.com/kewang.information/posts/2085843121692051
#socketio #websocket #log
