#純靠北工程師5cy
----------
小弟公司做iot的,從設備端到資料倉儲中心到手機remote app到串ERP都有做,最近公司遇到奇葩客戶,對方自己養了一個「寫了十年web的工程師」,然後叫我們做設備跟app就好,中間的溝通server該工程師堅持要自己寫,且業主要求在一季內完成所有項目,開會跟對方解釋如果對方工程師要從頭開始寫起要處理一大堆兩邊對接的問題等等各種雞毛蒜皮的事,建議用本公司既有的系統下去改商業邏輯的部分就好,結果對方工程師不斷跳針:「啊不就是mqtt跟http兩邊資料互傳就好,就是用api資料丟來丟去而已嘛,雖然我沒寫過但我不覺得這很難啊,只要知道api要傳哪些資料我也可以啦」各種貶低iot這行的言論,
當場我就想走人跟老闆說這案不要接,他說他行那讓他自己上......
同樣是碼農,隔行如隔山啊,有必要這樣把人家的工作講的一文不值嗎?
何況我還沒講到可能還會碰到要處理跟某些設備互傳udp封包指令的事,從頭到尾我看這傢伙只懂http跟websocket,只有一季時間要從零做到完到底自信哪來的,真的好想叫老闆放生這公司讓他們自己踩雷後再來求人......
----------
💖 純靠北官方 Discord 歡迎在這找到你的同溫層!
👉 https://discord.gg/tPhnrs2
----------
💖 全平台留言、文章詳細內容
👉 https://init.engineer/cards/show/6946
websocket server 在 Kewang 的資訊進化論 Facebook 的最佳解答
昨天在 frontend 社團有 backend 工程師來發問「一個要花費 20 秒的 API,backend 難道不能讓 frontend 等 20 秒再回傳給 frontend 嗎?為什麼有些做法都是先回 201 然後再用 websocket 回傳結果呢?」
當然可以啊,但使用者體驗會很差,這裡把昨天小編的回文拿回來再補充一下。
---
一個 20s 的 request 會遇到幾個問題
1. client 的話的使用者體驗很差,在瀏覽器等了 5s 我就想關網頁了,更何況 20s。
2. 如果使用者在 5s 的時候關網頁,這時候 server 還是會繼續把後面的 15s 處理完。
3. 如果使用者此時又發 request,然後在 7s 的時候又關網頁,這樣子有兩個耗時的工作在後端處理,而且還沒辦法讓前端知道。
4. 使用者都很沒有耐心,如果有 10 個人重複做了 2 3 步,這樣就有 20 個耗時的工作。
5. 如果是 CPU bound task,你的 server 應該會卡死。
6. client 跟 server 各自都有 timeout 的設定,而且 server 前面如果還有擋 nginx 或是其他 cloud provider 的話,光是 timeout 的設定就搞死你了。
---
建議的作法,把真的必要的工作處理完,threshold 最多設 3s,超過的一律丟到 MQ 處理。然後在前端顯示,請他稍後再回來更新網頁,這是最簡單的。每個系統 (OLAP 或 OLTP) 的 threshold 不同,請自行考量。
要不然 polling 也行,每 3 秒拉一次,確認工作是否完成。
最聰明的當然就是透過 push notification 或 websocket 讓 client 得知工作是否已完成。
---
https://hahow.in/cr/kewang-backend
看到這裡,要宣傳小編的後端課程啦!上面回答的這些內容,都會在課程裡面分享喔,還不快去下單!
#backend #frontend #mq
websocket server 在 Kewang 的資訊進化論 Facebook 的最佳貼文
剛剛在整理筆記的時候,發現兩年半前還在前公司就應該要發的文章一直躺在筆記裡面,快點整理一下 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
websocket server 在 WebSocket Server in TypeScript - YouTube 的美食出口停車場
How to build a server for real-time communication with WebSockets in TypeScript using the ws NPM package. Join the conversation on Discord ... ... <看更多>