# API gateway notes
一個位於clent與microservice之間的中介程式
## Benifits
1. Load balance(將負載適當的分攤到不同的 service 上，讓伺服器可以服務更多的使用者)
2. Authentication(我是誰?) and Authorization(我能做什麼?)
3. request routing(決定如何在分佈式系統中將用戶的請求（request）轉發到適當的服務或資源)
4. protocol translation(將 HTTP Request 轉換成 gRPC、TCP、UDP 後，送給內部的服務。)
5. Rate-Limiting(限制 API 請求的頻率)
6. IP Listing(設定 IP 黑名單、白名單)

## request/response cycle
當一個request進入api gateway且match到某個path&method後，就會進入request/response cycle，這裡共分四階段
1. method request
有一些驗證機制，驗證沒過的API call在gateway這邊就可以先回應error，而不用進到真正的backend service裡面，能夠過濾有問題的request。

# 功能
1. authentication and security policy enforcements
2. load balancing and circuit breaking
3. protocol translation and service discovery
4. monitoring, logging, analytics and billing
5. caching

## Workflow

1. 用戶發送一個request到api gateway

2. api gateway驗證這個http request

3. api gateway根據它內部設定的allow-list跟deny-list來檢查這個用戶的ip位址以及其他的http headers

api gateway還能針對ip位址和http headers等屬性執行基本的速率限制檢查，例如，可以拒絕某個ip位址超過一定速率的服務請求。

4. api gateway把這個request傳給identity provider進行身分驗證(authentication)和授權(authorization)

5. 經過驗證的session會套用更高等級的速率限制，如果超過這個限制，這個request就會被拒絕。

6+7. 在service discovery component的幫助下，api gateway可以透過路徑匹配到相應的backend service來處理request。

8. api gateway把request轉成適當的protocol，並把轉換後的request傳到backend service

當response從backend返回的時候，api gateway會把response轉換回public-facing的protocol，並把這個response傳給用戶。
註:我猜是因為內部的通訊協定跟外面的通訊協定可能不一樣，所以才需要做這個翻譯的動作

一個好的api gateway應該除了以上的基本功能外也要能夠具備以下的功能
1. error tracking
2. circuit breaking來防止服務過載
3. logging, monitoring, analytics來方便內部人員觀察各項service的metrics

# pros and cons
## 使用api gateway
### pros
1. 簡化客戶端開發：
- 客戶端只需與 API Gateway 交互，不需要知道後端的具體結構和地址。

2. 集中管理：
- 集中處理身份驗證、授權、日誌記錄、流量控制和監控等功能，統一管理和配置。

3. 負載均衡：
- 將請求分配到多個服務實例，實現高可用性和高性能。
4. 速率限制：
- 限制每個客戶端的請求速率，防止濫用並保護後端服務。

5. 緩存：
- 提供緩存機制，減少後端服務的負載，提升響應速度。

6. 協議轉換：
- 支持不同協議之間的轉換，例如從 HTTP 到 gRPC，簡化不同系統間的集成。

7. API 聚合：
- 將來自多個後端服務的數據聚合到一個響應中，減少客戶端與多個服務交互的需求。

8. 安全性：
- 集中處理安全相關的問題，例如使用 API 密鑰、OAuth 或其他認證方法來保護 API。

9. 日誌記錄與監控：
- 集中記錄和監控所有進出系統的請求與響應，便於問題排查和性能優化。

### cons
10. 單點故障：
- API Gateway 成為所有請求的必經之路，如果它出現故障，整個系統的可用性可能會受到影響。

11. 性能瓶頸：
- API Gateway 需要處理所有進出的請求，可能成為性能瓶頸，尤其是在高流量環境下。

12. 額外的運行成本：
- 部署和維護 API Gateway 需要額外的資源和運行成本。

13. 額外的延遲：
- API Gateway 會引入一些額外的延遲，因為每個請求需要通過它進行處理和轉發。

14. 複雜性增加：
- 引入 API Gateway 會增加系統的複雜性，需要專門的配置和管理。
15. 學習曲線：
- 使用 API Gateway 需要學習新的技術和工具，並且需要對其配置和管理有深刻理解。

## 不使用 API Gateway
### pros
1. 簡化架構：
- 沒有額外的中介層，架構更加簡單直接。
2. 減少延遲：
- 沒有中介層引入的額外延遲，請求和響應的速度可能更快。
3. 降低成本：
- 無需為 API Gateway 的部署和運行付出額外的資源和成本。
4. 減少單點故障：
- 不存在 API Gateway 作為單點故障的風險。
### cons
1. 客戶端複雜性增加：
- 客戶端需要知道並處理多個後端服務的地址和細節，增加了開發和維護的複雜性。
2. 分散管理：
- 身份驗證、授權、日誌記錄等功能需要在每個服務中單獨實現和管理，難以統一配置和管理。
3. 負載均衡困難：
- 需要自行實現和管理負載均衡機制，增加了系統的複雜性。
4. 安全性挑戰：
- 每個服務需要單獨處理安全問題，增加了潛在的安全風險。
5. 缺乏速率限制：
- 無法集中管理和實施速率限制，增加了後端服務被濫用的風險。

## ref
1. https://www.youtube.com/watch?v=6ULyxuHKxg8&ab_channel=ByteByteGo
2. https://vocus.cc/article/6205b160fd897800013c841c
3. https://www.apiseven.com/blog/why-we-need-apache-apisix
4. https://apisix.apache.org/zh/