Rate limit的用意是避免服務被濫用, 檢查的機制是在一定時間內被同一用戶呼叫的次數
而限制又根據stream, 和request來做區分

stream是 一分鐘需要低於10次, query則是20次

stream會訂得比較嚴的原因是會建立socket, 佔用連線頻寬
另外我們還要做concurrency的機制 不要讓同一個用戶同時建立多個連線佔用頻寬

在bff層 我們會再登入後取得用戶的mail來當作計數的key
避免同一用戶試圖開多視窗同時連線

而slowapi 則可以針對不同的handler (query, stream)
給出每分鐘的次數限制

除了後端的rate limit, 前端在觸發限流時也該被告知

1. 超過limit 需要等候的通知
2. 需要等候多久的倒數, 這可以由slowapi提供的秒數做到

不過因為我們的服務是跑在cloudrun, 彼此是獨立的
如果用戶多開網頁來存取服務, 我們是無從判斷, 這就要加上radis來確保同一帳戶的連線數量
但在這階段就先不增加radis了

如果遇到limit狀況前後端會出現的反應
畫面上是故意調低limit次數, 當偵測到太頻繁請求 就送出錯誤 讓前端disable送出並且倒數秒數
後端的log則是可以看到429 錯誤

接著加上一些log 從bff送出 這樣cloud run就可以接收並且從cloud log查詢紀錄
這部分就是CES無法看到只有從bff回報的log