> For the complete documentation index, see [llms.txt](https://gan-mongklakorn.gitbook.io/notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://gan-mongklakorn.gitbook.io/notes/software-architecture/microservices/api-gateways.md).

# API Gateways

พอเรามี Client (web, mobile, ...) กับ Services ก็จะเริ่มมีปัญหาอย่าง Complexity ที่เรียกจาก UI ไปยัง Services ทำให้ ui หรือ client ต้องรู้จักกับ services ข้างหลังจำนวนมาก หรืออาจจะเป็นการเรียกไปยังหลายๆ protocols ที่ข้างหลังใช้ ทำให้โค้ดของ UI มันซับซ้อนมากขึ้นไปอีก และบาง protocol client ไม่รองรับอีก รวมไปถึงการทำให้ microservices ข้างหลังต้องเปิดเป็น Public endpointทำให้ปัญหาที่ตามมาเยอะมากๆ

เราเลยมีสิ่งที่เรียกว่า API Gateways มาช่วยจัดการ services ข้างหลังให้สามารถคุยกับฝั่ง Client ได้ ทำให้โค้ดฝั่ง Client ง่ายมากขึ้น ทำให้ทั้งสองฝั่งไม่ต้องรู้จักกัน ทำให้มัน Cross-cutting concerns ด้วยก็คือ คนที่ทำ Authentication, Authorization, SSL,... มันจบตั้งแต่ API Gateways เลย ไม่ต้องมาทำกับทุกๆ services และทำให้ service สามารถรองรับได้ทุก client ด้วย

<figure><img src="/files/l2zAHsWjkNBr7wrERuNd" alt=""><figcaption><p>ตัวอย่าง Design ที่มี API Gateway</p></figcaption></figure>

Patterns

* Gateways Routing Pattern
* Gateways Aggregation Pattern
* Gateways Offloading Pattern

### Gateway Routing Pattern

Route to **multiple microservices with single endpoint** หรือ มันจะ route ไปยัง internal backend microservices ข้างหลังให้เลย จาก request ของเรา ข้อดีคือถ้า Service ข้างหลังเปลี่ยน เราจะไม่ต้องแก้อะไรที่ client

มันเป็นการ abstracts backend microservices ของเรา จาก client ซึ่งจะทำให้โค้ดฝั่ง client มัน simple ไปอีก รวมไปถึงทำให้การ deploy อย่าง blue/green หรือ canary ได้ด้วย แค่เปลี่ยน api gateway ทำให้มัน **Flexible**

<figure><img src="/files/7LQqOlH3bpr8ucTJjbP2" alt=""><figcaption></figcaption></figure>

### Gateway Aggregation Pattern

คล้ายๆกับอัน routing แต่จะเป็นการ Aggregate Multiple individual request to microservices with exposing single request to client หรือการที่มันจะคิด logic อะไรให้เราเสร็จสับ ไปจนถึงเรียก services ข้างหลังให้เราเลย ใน endpoint เดียว เช่นในกรณีที่ client จะทำอะไรบางอย่าง อาจจะต้องเรียกหลาย services ข้างหลัง อันนี้เพียงแค่เรียก api gateways ครั้งเดียว ละ api gateways จะทำให้ ทำให้โค้ดของ Client ง่ายขึ้นไปอีก (แต่ gateways ซับซ้อนขึ้นนะ)

<figure><img src="/files/ZAVYu78J1FO2DbaiYjz7" alt=""><figcaption></figcaption></figure>

### Gateway Offloading Pattern

คือการที่รวม Functionalities มาไว้ใน gateways ด้วย เช่น Authentication, Authorization, Rate limiting, SSL, Logging, Monitoring, Load Balancing เพราะว่าการที่เอาทุกๆอย่างในนี้ไปใส่ไว้ใน Service มันอาจจะไม่ดี ทำให้ services ข้างหลังมันง่ายมากขึ้น focus แค่ฟังก์ชั่นอย่างเดียว

<figure><img src="/files/7u5fd0IACN1WYNzpRPwR" alt=""><figcaption></figcaption></figure>

#### ข้อดี

* ทำ Routing, Aggregation, Reverse proxy ได้เลย
* ทำให้ Backend Service มันง่ายขึ้น คุยกับ Client ได้ง่ายขึ้น
* ลด Network Traffic จาก Client ได้
* ทำ Functionalities หลักๆ ได้เลย ไม่ต้องทำทุก Services
* Client focus กับแค่ interface อย่างเดียว logic การทำงานว่าจะไปหา services ไหน จะอยู่ที่ gateways&#x20;

#### ข้อเสีย

* เป็น Single point of failure
* API Gateway จะมี logic ด้วย เพิ่มจุดที่ต้องแก้ไขไปอีก
* ต้อง Scale ให้ดี รับ traffic เยอะ
* Latency เยอะขึ้น เพราะว่ามีขึ้นตอนเยอะขึ้น (แต่ก็เร็วขึ้นได้เหมือนกัน เพราะว่า api gateways อยู่ที่เดียวกับ services ด้านหลัง ถ้าเรียกหลายอันจะทำให้ลด overhead ได้เยอะ)

โดยที่ Pratices ที่นิยมกันก็คือ **BFF หรือ Backend-for-Frontend Pattern**

### Backend for Frontend Pattern (BFF)

เอามาเป็น API Gateways สำหรับ Client นั้นๆ เพราะแต่ละ client อาจจะมี logic ไม่เหมือนกัน bff จะเป็นตัวที่แปลง request ที่หลากหลายนั้นเป็นอย่างเดียวกัน ตาม services ด้านหลัง

<figure><img src="/files/9Z8ixjs9qQGqrivUpEaX" alt=""><figcaption><p>Backend for Fronend (BFF) Design</p></figcaption></figure>