API Gateway

هو نقطة الدخول الوحيدة لكلّ الـ requests اللي يجيو من الـ clients للـ backend. معناها عوض ما الـ client يحكي مع كل service وحدها، يتعامل كان مع الـ Gateway، والـ Gateway يتكفّل بالباقي.

المقدّمة

في الزمن متاع الـ Monolithic Applications، الـ client ما كانش يتعب برشا، يحكي مع Service وحدة والسلام، ما يلزمش يعرف شنوّا صاير داخل الـ backend.

أمّا كي دخلنا في عالم الـ Microservices، الـ Monolith تكسّر لعدة Services صغار، كل واحدة عندها boundaries متاعها.

وتوّا يجي السؤال:
شنوّا نعملو في الـ client؟ قبل كان يبعث request لمكان واحد، توا لازم يبعث requests لعدة services.
كيفاش باش نـmanage التغييرات كي تبدّل endpoints؟
معقول الـ client يكون مربوط بشكل مباشر وقوي بكل service في الـ backend؟

من غادي بدينا نفكرو:
علاش ما يكونش عنا نقطة دخول واحدة، تنظّم طلبات الـ users، وتوجّهها للـ services اللي لازمة داخل الـ system؟
وهكّا نجم نبدّل في الـ backend كيما نحب طالما الـ interface اللي يستعملو الـ client ما تبدّلش.

ومن هنا جات فكرة الـ API Gateway. خلّينا نشوفو بشويّة بشويّة شنوّة هو بالضبط وشنوّة يعطي من فوائد.

---

API Gateway

الـ API Gateway هو single entry point لكلّ الـ requests اللي يجيو من الـ clients.
الـ client يتعامل مع gateway واحد، وهو يقوم بالتوجيه، التحقق، الحماية، وكلّ شي.

---

API Gateway Benefits

الـ API Gateway موش مجرد نقطة دخول، يعطي برشا مميزات:

Dynamic Routing

تخيّل فمّا 10 microservices، وكل وحدة عندها endpoint مختلفة.
الـ frontend لازم يعرفهم الكلّ.
ومعناها يلزم ينسّق requests مع كل service.

لكن مع الـ gateway، يتعامل مع واجهة واحدة، وهو يعمل routing للباقي.

Authentication & Authorization

نجمو نحطّو layer متاع auth داخل الـ gateway،
وما نكرّروش نفس الكود في كل service.

Rate Limiting & Throttling

نحدّو عدد الطلبات اللي user ينجم يبعثهم في وقت معيّن ⇒ حماية ضدّ DDoS وغيره.

Parameter Validation

الـ gateway ينجم يتحقّق من الـ parameters قبل ما يوصلو للـ backend.
مثال: userId يكون integer، ما يكونش string.

Allow / Deny List

نجم نسمحو أو نمنعو الوصول حسب:

• IP Address
• API Keys
• Tokens
• Geo-Restriction

Service Discovery

في بيئات كيما Kubernetes، الـ IPs تتبدّل.
الـ API Gateway يتعامل مع Consul وإلا Eureka، ويعرف الـ services وين موجودة.

Protocol Conversion

عندك backend يخدم gRPC ولا SOAP،
والـ client ما يدعمهمش؟
الـ gateway يحوّل البروتوكول لحاجة مفهومة للـ client.

Caching

الـ gateway ينجم يكاشي responses ويقصّر الوقت على الـ backend.

---

API Gateway Tools

بعض الأدوات المعروفة:

• Kong: قوي برشا، مفتوح المصدر، مبني على Nginx.
• AWS API Gateway: Managed من Amazon.
• Istio Gateway: جزء من Service Mesh.
• Traefik: مشهور في عالم الـ containers وخاصة Docker/Kubernetes.

---

وقتاش ما نحتاجوش API Gateway؟

• كان الـ app صغير برشا.
• كان الـ communication داخلي فقط.
• كان الـ overhead متاع gateway أكبر من الفايدة.

---

في الختام

الـ API Gateway عنصر أساسي في تصميم الـ systems الحديثة، خاصة مع microservices.
يعطي abstraction نظيفة، ينظّم الـ communication، ويوفّر مميزات بلا ما نكرّروهم في كل service.

سؤال ليكم:
شنوّا الفرق بين Reverse Proxy و API Gateway؟
ويا ترى، هل نجمو نخدمو بأكثر من API Gateway في نفس الـ system؟