المقدمة

في ظل وجود الـ Monolithic Applications ، الـ Client هنا مش بيتعب في انه يتواصل مع الـ Backend وده لإنه بيكلم Service واحدة في الأول والآخر ومش محتاج يشغل باله من أي مشاكل.

ولكن مع التقدم اللي حصل وبعد هوجة و Trend الـ Microservices بيبدأ الـ Monolithic Application ده يتكسر لـ Services صغيرة كل واحدة محدودة بالـ Boundaries بتاعتها.

وبيجي هنا السؤال اللي بيحير الناس ، يا ترى هنعمل ايه في الـ Client ؟ احنا كنا بنبعت Request لمكان واحد دلوقتي محتاجين نبعت Requests مختلفة لكل الـ Services دي. طب ازاي هنـ Manage التغيير اللي ممكن يحصل لو Endpoint اتغيرت ؟ وهل مفروض الـ Client يكون Coupled بالشكل العنيف ده مع كل Service في الـ Backend لما تتغير؟

وهنا بدأنا نفكر في اننا ليه مايكونش عندنا نقطة دخول واحدة بتتحكم في طلبات المستخدمين وبتوجهها للخدمات المناسبة جوا النظام ؟ وبالتالي اقدر اغير براحتي اي حاجة في الـ Backend طالما الـ Contract أو الـ Interface اللي بيستعمله الـ Client واحد.

ومنا هنا جت فكرة الـ API Gateway ، فخلونا نشوف مع بعض ايه هو والمميزات اللي بيقدمهالنا بالورقة والقلم 🚀

API Gateway

الـ API Gateway هو نقطة دخول واحدة (single entry point) لكل الـ (requests) اللي جايه من الـ clients للـ backend. فبدل ما الـ client يتعامل مع كل service بشكل مباشر، هو بيتعامل بس مع الـ Gateway، والـ Gateway يتولى الباقي.

API Gateway Benefits

الـ API Gateway مش بس نقطة دخول موحدة للـ APIs، لكنه بيقدّم مجموعة كبيرة من المميزات:

API Gateway
API Gateway
  1. Dynamic Routing
    خلونا نتخيل إن عندنا 10 microservices، وكل واحدة فيهم ليها endpoint خاص بيها. بالشكل ده الـ frontend محتاج يتعامل معاهم كلهم بنفسه!
    وده معناه إنه لازم يعرف كل endpoints ويبدأ ينسق الـ requests اللي بيبعتها لكل واحد فيهم.
    ولكن من خلال استعمال الـ Gateway، الموضوع ده بيبقى أبسط، لأنه بيتعامل مع واجهة واحدة.
  2. Authentication & Authorization
    من ضمن المميزات القوية للـ API Gateway هي إننا ممكن نضيف layer من الـ authentication و authorization جوه الـ API Gateway نفسه، بدل ما نكرّر نفس الكود ده في كل service.
  3. Rate Limiting & Throttling
    نقدر نحدّد عدد الطلبات اللي المستخدم يقدر يبعتها في وقت معين.
    وده طبعًا بيساعد في الحماية من الهجمات زي DDoS.
  4. Parameter Validation
    الـ Gateway بيقدر يعمل تحقق من صحة البيانات اللي جاية في الطلب قبل ما يوصل الـ backend.
    مثال: لو عندك API بتطلب userId كـ query parameter، ممكن تتأكد إنه رقم، مش نص، وإنه ضمن نطاق معيّن.
  5. Allow / Deny List
    ممكن نعمل قوائم لتحديد مين يقدر يوصل للـ APIs وده من خلال أكتر من حاجة زي الـ IP Address , Tokens, API Keys, Geo-Restriction
  6. Service Discovery
    لو بنشتغل في بيئة Containerized (زي Kubernetes)، الخدمات ممكن تتغير الـ IPs بتاعتها.
    فالـ API Gateway يقدر يشتغل مع أنظمة Service Discovery (زي Consul أو Eureka)، ويحدد أماكن الخدمات بشكل تلقائي.
  7. Protocol Conversion
    لو عندنا خدمات شغالة بـ بروتوكولات مختلفة (زي gRPC، SOAP، WebSocket)، والـ clients مش بيدعموها، الـ API Gateway يقدر يعمل تحويل بين البروتوكولات دي لحاجة تكون مدعومة.
  8. Caching
    الـ Gateway يقدر يحتفظ بنسخة مؤقتة من الـ responses للطلبات المتكررة، ويستخدمها بدل ما يرجع للـ backend كل مرة ويجيب البيانات دي.

API Gateway Tools

فيه أكتر من Tool نقدر نستعملها كـ API Gateways:

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

أمتى ممكن ما نحتاجش API Gateway؟

  • لو التطبيق بسيط ومكوّن من خدمة واحدة أو خدمات قليلة جدًا.
  • لو الـ communication بين الخدمات داخلي فقط ومفيش interaction مباشر مع clients خارجيين.
  • لو الـ overhead اللي هيسببه الـ Gateway أكبر من الفايدة اللي بيقدمها.

في الختام

الـ API Gateway هو عنصر مهم جدًا في تصميم الأنظمة الحديثة، خصوصًا لو شغالين بنظام الـ Microservices. لإنه بيوفر abstraction ممتازة، وبيسهل الـ Communication، وبيقدّم مميزات كتير من غير ما نكرّرها جوه كل service.

سؤال ممكن تفكروا فيه ايه الفرق بين الـ Reverse Proxy والـ API Gateway ؟ ويا ترى لو هل ممكن يكون عندنا في الـ System أكتر من API Gateway وامتة ؟