值得慶祝的文章區塊第一篇文章， 就決定是「你推多久沒開台了」服務的程式解密了！

服務網址：https://last-live.starknows.tw/

不過這個小玩具其實沒有太多厲害的東西， 有的就是一些窮小子的花招而已（ 這邊會簡單講解一下自己開發時的思路。

首先直接來個文字版的流程圖：

1. [前端] 取得帳號代碼、驗證帳號代碼 2. [前端] 發請求給雲端服務 3. [後端] 接收請求、驗證帳號代碼格式 4. [後端] 對目標頻道之直播頁面發送請求 5. [後端] 取回 html 文件後進行文本分析 6. [後端] 取出 YT 埋在 html 之中的直播列表資料結構 7. [後端] 處理結構化資料，找出第一筆「直播存檔」並記錄 ID 8. [後端] 進行第一次錯誤處理與回應 9. [後端] 確認直播快取資料，確認是否曾有同一場直播資料 10.[後端] 若有快取，取出快取資料 -> 接 12. 11.[後端] 若無快取，透過 DataAPI v3 取得該場直播資料 12.[後端] 確認是否有頻道資料快取 13.[後端] 若無，透過 YT RSS 服務取得頻道資訊 14.[後端] 從頻道資訊挖掘綠界、山羌服務網址 15.[後端] 將頻道資訊存入頻道資料快取 16.[後端] 整合直播資料與頻道資訊，回應前端 17.[前端] 接收回應，處理 UI 呈現，啟動計時器

沒有什麼技術含量，略過不談。

這邊會對 https://www.youtube.com/${channelId}/streams 進行 GET 請求 因為 Youtube 運用了某種 SSR / Hydration 的技術處理網頁 所以會在伺服器端取得資料並且塞在 Html 當中回傳， 讓瀏覽器端程式自行取出資料後進行網頁渲染 這邊就是利用了這點，透過正規表達式將 Html 當中的直播資料取出。

問：為什麼不透過 Data API 好好的取得資料？ 答：因為 quota 不夠用。

Youtube 的 Data API 有每日的 quota 限制 雖然使用者付費是天經地義的事情， 但是這個 quota 只能透過聯絡 Youtube 官方提案合作的方式增加 目前暫時不考慮這種麻煩的事情。

而為了取得特定頻道最後一筆直播的資料， 可能會需要花費 100 quota 進行 Search 請求 這樣的話，每日 10000 的 quota 可能沒幾下就會用罄

在處理直播資料的時候 畢竟不是透過正規方式取得資料 要判斷每一筆資料的性質就會比較麻煩 因為直播頁籤中的影片會有以下這幾種狀態： 直播中 / 待機室 / 直播存檔 要怎麼從簡化的資料中判斷是哪種狀態，就需要去判讀資料的關鍵差異 我最後的判斷依據是： if 有顯示觀看人數 = 直播中 if 有倒數計時 = 待機室 if 有發佈時間 = 直播存檔 在這個階段，如果發現頻道正在直播中就會直接回應前端，並且在網頁顯示直播中的提示 畢竟直播中的頻道就沒有確認「你推多久沒開台」的這個大前提。 而另一種狀況就是，目前確認中的頻道從未進行過任何的直播。

為了減少使用 Data API 的次數 我會建立一個 Map ，寫入 頻道ID/最後一場直播資料 的 鍵值對， 如果該頻道 ID 的快取資料，其影片 ID 等於 7. 的影片 ID， 就代表這個頻道在上次查詢之後還沒有進行過任何的直播， 而我也可以直接用之前快取的資料進行回應， 避免又多花 1 quota 去取得手上已經有的資料。 光是加上這個步驟，就可以大幅拓展我的服務韌性， 畢竟一但有人查詢完，在社群發佈了截圖或者連結， 後續就會持續湧入相同的查詢請求，可能會造成無謂的 quota 浪費。

如果是直接透過 API 查詢最後一場直播的資料，可能會需要 100 quota 但我已經透過分析 Html 文本確認了最後一場直播的 ID 就可以直接查詢這場直播的相關資料，而且額度只需要花費 1 quota 所以雖然很迂迴且浪費效能的先 GET 了整個網頁回來分析才打 API， 我卻得到了 100 倍的服務次數上限。

在服務推出第一版的時候， 這邊側面接收到了來自 麵音白湯(@PaitanOfficial) 的回饋 提到說如果能附上山羌的連結就好了。

不過若要幫所有的 台V 建立資料庫，聽起來實在太不切實際了 所以在花了一點時間思考後，意外發現了 Youtube 其實有 RSS 服務 只要透過特定的網址就可以關注/確認特定頻道的最新動態， 而這個動態，其實就是影片發佈的通知，每發一部新片就會有一筆資訊。

接下來就是人與人之間的信任問題了（

因為頻道主只要擁有綠界或者山羌的抖內管道， 肯定會在每部影片底下的資訊欄書寫相關資訊， 所以我只要掌握綠界跟山羌的網址格式，就可以擷取出抖內網址。

這邊也沒有什麼技術含量， 單純就是將最後一次直播的結束時間傳送至前端， 然後前端根據這個結束時間點，計算經過的時間， 最後再啟動一個計時器讓時間繼續前進。

長期以來作為一個觀眾，其實並沒有想過會有發佈服務並獲得關注的一天， 原先也只是在 金魅(@Kintsuai) 的粉絲 DC 當中開玩笑般地製作了專屬的服務， 後續才有了將服務拓展到能針對所有的頻道進行查詢的想法。 也是因為碰巧在阿發發的棉花糖發文底下回應， 才有了最後累積數十萬次觸及的擴散結果， 確實是一次很特別的經驗。

最後， 身為一個社畜，其實腦袋很難一直有新的點子冒出來， 但自認是(同時在公司也是)屬於願望機類型的工程師， 所以如果有任何天馬行空的想法，或許是能透過程式的方式達到的， 都歡迎隨時透過郵件或 DC 與我聯繫， 畢竟我喜歡各種有趣的事情。