نقطة دخول واحدة لكل الـ requests اللي جايه من الـ clients للـ backend. فبدل ما الـ client يتعامل مع كل service بشكل مباشر، هو بيتعامل بس مع الـ Gateway، والـ Gateway يتولى الباقي.
في ظل وجود الـ 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، لكنه بيقدّم مجموعة كبيرة من المميزات:
