最近因為在找新工作，同時也需要把一些知識打穩，既然常在寫 side project，那麼一定要對於 http 請求後發生什麼事、SSL、OAuth、OpenID 都需要理解清楚，否則串了這麼多服務也寫了應用，但在關鍵時沒講出來的話作品就發揮不出它的功用了 😞，那麼以下就會用我的觀點以及紀錄方法來敘述這些功能。
註：若有發現有什麼問題或內容有誤的話麻煩再留言讓我知道，或是
寄信給我也是可以喔！
https://www.google.com之後發生了什麼事?首先須了解https://www.google.com這樣的網址是如何組成:
約在一年前，當時公司的同事帶我玩過 Swagger，只是當時的我寫得不太習慣，直到寫這篇之前都還只是寫 markdown 來做 API 文件 😓，不過寫 API 到最後總是要開放給其他人需要測試以及用文件來描述功能，但只是寫 Readme.md 給其他人看感覺有點不負責任 (?)，所以這個時候 Swagger 就發揮它的作用啦～
但是看著下面這張圖…
左邊那是怎樣！怎麼設定了一大堆右邊才出現一點點東西，估且不論還要設定 Model、Payload 什麼的，我想光寫左邊這份文件加測試的時間我都可以寫一份 Markdown 給其他同仁用 Postman 測試了…🤣🤣🤣
這時候套件就出動啦，這次要介紹的是 flask-restful-swagger-2.0，他是延續原版套件並加以更新的，不得不說再搭更新完後整體寫起來人性多了，像是文先寫法用 decorator 的寫法在路由之前、宣告 Schema 時只要用類別包起來之類的，讓寫文件可以用 python 的寫法去寫，除了特殊的設定需要比對 Swagger 官方文件外，在建一個 Swagger 格式的文件這樣已經超快了 💪
既然如此那就介紹一下他的相關設定並把它記錄下來吧！
對於 LINE Notify 其實早早就一直有在使用，不管是 server 健康檢查、空汙通知、直播主開台通知...等，都一直使用著，也是因為一直在用時有個困擾，就是每次都要找 API 文件並且看對應的參數...這在開發流程上浪費了不少時間，也因為到 Pypi 套件庫裡找 LINE Notify 相關套件時大多都只有推送功能，幾乎沒有對於認證流程的操作的 function ，文件也不齊全，在此同時也看到卡米哥的 GitHub 在此時上傳了一個 Notify SDK，畢竟我對 Ruby 還不算陌生，就直接參考卡米哥的架構並加上單元測試來完成本篇要介紹的 - Lotify
在 AWS 的 API gateway 上就有一個項目(Authorizer)是支援 Cognito 以及客制認證的方法，好處就是在進我們寫的 API 之前有個可以做身份確認的 Lambda Function 幫我們好前處理，而本篇則會介紹如何在 Serverless framework 上設定 API gateway 的 Authorizer 以及成功讓 API 回應，串接 Cognito 做使用部分就留給之後吧！
因為遇到了很多不算坑的坑(說啥呢？)，有些是文件沒有寫而有些可能是我沒有注意到的，但既然都知道了就乾脆記下來吧！
字面上看起來很像 Push Message 的事件，但實際上是走 Flex Message，使用 Message api 的 Reply 功能來幫忙使用者發送條件引發 Bot 行為，並非是透過 Push api 發送讓 Bot 反應，這邊需要多注意喔！
liff.sendMessages([
{
type: "text",
text: "You've successfully sent a message! Hooray!",
},
]);
最近 LINE 釋出了一個我很喜歡的功能 - Icon Switch🎚，從字面上的意思就是可以切換機器人的 Icon (名稱以及大頭貼)，過往開發者在使用時都只能較死板的使用同一個頭像或暱稱來回應使用者，而現在只要使用這個這個功能就可以很輕易地切換你想要的大頭貼以及暱稱了 😇
據可靠消息指出這以前是需要收費的功能，而現在則是免費推出來給大家使用，讓大家可以有更多的彈性去開發新功能～
有一次在網路上閒逛的時候看到了這篇部落格，裡頭透過一些簡單的敘述來展示 Typescript 跟別人不太一樣的地方，也說到一些需要注意的眉角，這次文章則含有些許的文章翻譯以及個人評述在裡面，以下就開始吧！
最近一次的 Chatbot 小聚因為在疫情期間可預期現場來的會眾一定不多，所以在這場小聚中也加上線上直播的部分，但因為我首次導入還不是很熟悉，在谷歌大神的幫忙下找到本篇介紹的軟體 - Streamlabs，使用 XR 錄影起來的品質覺得還不錯，且連講者 Demo 時的 LINE token 都看得一清二楚 🤣，接下來就來介紹一下我使用的過程。
這邊我使用 iOS 做範例，小聚資訊可以參考 Chatbot GitHub
之前鐵人賽寫了一篇文章有提到 Cold Start 的問題，不過只有粗略介紹，最近看到大家忽然又開始討論這個話題，這次就來好好的搜尋資料介紹一下。
平常在做 open source 時比較常遇到休眠狀態應該就是 Heroku，而開頭要先澄清一下他是屬於 PaaS 的架構，而 AWS、Google、Azure 裡提供的 Lambda、Cloud Run、Azure Function 這些則屬於 FaaS 架構，而最常討論 Cold start 時最常會在 FaaS 上討論，只是剛好 Heroku 使用起來也是一樣，這次文章就把他一起抓進來討論啦～
有很多各式各樣的服務，SaaS、FaaS、KaaS、IaaS... 等各式各樣的架構，每個都是為了解決某個問題所誕生的，至於好或不好其實就是看使用場景而定，所以大家在選用時要注意一下你使用的場景哦！
一般會有休眠機制是因為這些供應商在提供服務都是提供按次計費的方案，讓開發者在用時可以需要才喚醒使用，也就是說這些服務都是 事件驅動(Event-Driven)導向，意指是當前服務若收到訊息後，會呼叫對應的 Function 來處理對應服務所接收到的資料(Queue、Notify ...)，但相對的就是會有休眠讓服務暫停，進而讓較少使用的服務不會因為掛在線上而一直被收費用，而重新啟動這件事就是本篇要提的Cold start。
在處理資料之後過一段時間若沒有繼續執行，雲端供應商會將模組暫停，此時 function 會處於 inactive 狀態(cold)，而當 function 再度被觸發時(cold start)則會再啟動模組來執行對應 function 來處理事件，在模組與 function 之間的關係可以稱他們為 Function chain。
以 AWS 為例，在喚醒時會到 S3 去取得檔案，接著找到相關的 Lambda 並載入相關模組套件，然後再執行觸發的事件，整理過後的下:
事件處理 ➡️ 過段時間 ➡️ 暫停 function 模組(休眠) ➡️ 觸發 ➡️ 啟動 function 模組 ➡️ 事件處理...
這整個流程就是俗稱的 cold start，因為在這個過程中會花些時間，所以若是拿來處理 api 相關問題的話就會有第一批請求很久，然後之後的請求卻特別快的狀態，請大家莫急莫慌莫害怕呀！
| 平台 | 多少時間後暫停 |
|---|---|
| AWS Lambda | 10 minutes |
| Google Cloud Functions | 介於 3 minutes 之間 5+ hours 都有 |
| Azure Functions | 20 minutes |
| Heroku | 30 minutes |
前三個為
FaaS架構，而 Heroku 則為PaaS架構喔！
下圖則來自 2019/09 的一篇文章，較深色的部分則為啟動時間。
以我熟悉使用 serverless framework 部署到 AWS 來說，他們提供了一個 warm-up 的套件，可以設定排程時間讓這個 function 固定去戳其他 function，避免他們進入休眠的狀態，雖然這樣子就能達到跟一般服務一樣的常駐狀態，不過相對來說就要注意次數的使用問題，若是流量還小的話沒什麼問題，但若有一定的流量就須注意一下帳單，因為這些在互戳的過程中還是有算進費用的喔！使用上還要多注意才行。
另一方面要注意相依套件的問題，引用 google 文件的其中一段:
謹慎使用依附元件，如果您使用動態語言搭配相依的程式庫，例如匯入使用 Node.js 的模型，這些模組的載入時間會增加冷啟動期間的延遲時間。您可以透過以下方式縮短啟動延遲時間：
畢竟在載入模組的時候相依套件也是要一起抓進來，若是程式本身太多依賴的話也是會導致 cold start 的時間變長哦！
最後就在幫大家整理一下三大平台的 warm-up 資源：
為什麼要有 cold start 的機制，以供應商的角度來說他們可以提供一定的量讓使用者免費在平台上先建置服務，但若要免費就是服務會被暫時暫停，畢竟現在流量就是錢嗎 💰，像我常用的 Heroku 就會是這樣，而當你流量大的時候就看你要不要搬家，不過一般應該都懶得搬，就會形成所謂的養、套、殺🤣(離題)。
總而言之，若是需要服務時常活著，就是需要付出點流量的錢 💰，也或許你的作品服務時間可能不用那麼長，只要在服勤時間內長駐活著就可以在省下一些費用，如果有需要的話還是付一些錢給供應商，畢竟人家也幫你保管了服務你說是不是？
