يا جماعة الخير، السلام عليكم ورحمة الله وبركاته. معكم أخوكم أبو عمر.
بتذكر قبل كم سنة، كنا في شركة ناشئة، فريق صغير وقلوبنا مليانة حماس. قررنا نتبنى معمارية الخدمات المصغرة (Microservices) من البداية، قلنا “بدنا نكون مودرن ونواكب التطور”. كان عنا خدمة للمستخدمين (Users)، وخدمة للمنتجات (Products)، وخدمة للطلبات (Orders). كل خدمة شغالة لحالها، قاعدة بياناتها لحالها، وكل شي تمام التمام… أو هيك كنا مفكرين.
المصيبة بلشت تبين لما كبر المشروع شوي. فريق الواجهة الأمامية (Frontend) صاروا يلطموا! عشان يعرضوا صفحة طلب واحد، كانوا بحاجة يعملوا ثلاث طلبات: واحد لخدمة المستخدمين عشان يجيبوا تفاصيل العميل، وواحد لخدمة الطلبات نفسها، وواحد لخدمة المنتجات عشان يعرضوا تفاصيل المنتجات اللي بالطلب. وكل خدمة من هدول، إلها طريقة مصادقة (Authentication) شكل! هاي بدها Basic Auth، وهذيك بدها JWT token مولّد بطريقة معينة، والثالثة لسه على نظام قديم. صارت حوسة ما بعدها حوسة، والشباب بالفرونت إند كل يوم يتصلوا عليّ: “يا أبو عمر، مش عارفين من وين نبلش! أي توكن نبعث؟ ولأي سيرفر نحكي؟”.
الضربة القاضية كانت لما قررنا نضيف نظام صلاحيات (Permissions). صرنا بدنا نعدّل كود المصادقة في كل خدمة على حدة. وقتها حسيت إنه “وقعت الفاس بالراس”، وإنه لو ضلينا هيك، المشروع راح ينهار تحت وطأة التعقيد. وهون، بعد ليلة طويلة من البحث والتفكير، لاقيت المنقذ: الـ API Gateway.
ما هي بوابة الواجهات البرمجية (API Gateway)؟
ببساطة شديدة، تخيل عندك عمارة فيها شقق كثيرة (هي الخدمات المصغرة تبعتك). بدل ما كل زائر يروح يخبط على باب كل شقة ويسأل مين فيها وكيف يدخل، بنحط موظف استقبال (رجل أمن) على باب العمارة الرئيسي. هذا الموظف هو الـ API Gateway.
أي حدا بده يدخل العمارة، لازم يمر على هالموظف. الموظف بتأكد من هويته (Authentication)، وبشوف هل مسموح له يدخل هاي الشقة تحديداً ولا لأ (Authorization). وبعدها، بوجهه للشقة الصحيحة. الزائر ما بعرف أصلاً شو أرقام الشقق أو وين مكانها بالضبط، هو بس بتعامل مع موظف الاستقبال.
فالـ API Gateway هي طبقة وسيطة بتجلس بين العميل (تطبيق الويب أو الموبايل) وبين خدماتك المصغرة المتعددة. هي نقطة الدخول الوحيدة لنظامك بأكمله.
المشكلة قبل البوابة: جحيم الإدارة المشتتة
قبل ما نستخدم البوابة، كانت حياتنا عبارة عن مجموعة من المشاكل المتكررة اللي استنزفت وقتنا وجهدنا:
- تكرار منطق المصادقة (Authentication Duplication): كل خدمة كانت مسؤولة عن التحقق من الـ JWT token وفك تشفيره والتأكد من صلاحيته. أي تحديث على آلية المصادقة كان يعني تعديل الكود في 3-4 أماكن مختلفة، وهذا كان باب كبير للأخطاء والنسيان.
- فوضى التوجيه (Routing Chaos): العميل (الفرونت إند) كان لازم يعرف عنوان كل خدمة من خدماتنا.
users.api.ourcompany.com،orders.api.ourcompany.com، وهكذا. هذا بيزيد التعقيد على العميل وبيكشف عن البنية التحتية الداخلية لشبكتنا. - صعوبة المراقبة والتحليل (Difficulty in Monitoring): إذا بدنا نعرف كم طلب إجا على النظام كله خلال آخر ساعة، كنا بدنا نجمع سجلات (logs) من كل الخدمات ونحللها، عملية معقدة وبطيئة.
- الحماية والأمان (Security): كل خدماتنا كانت معرضة بشكل مباشر للإنترنت العام، وهذا بيزيد من مساحة الهجوم (Attack Surface) المحتملة.
الحل مع البوابة: كيف أنقذتنا الـ API Gateway؟
لما طبقنا الـ API Gateway (وقتها استخدمنا حل مفتوح المصدر اسمه Kong)، تغيرت الصورة 180 درجة. صارت البوابة هي اللي تتعامل مع كل هالصداع، والخدمات المصغرة صارت “مرتاحة” ومركزة على شغلها وبس.
1. مركزية المصادقة والتفويض (Centralized Authentication & Authorization)
هاي كانت أكبر فائدة بالنسبة إلنا. كل الطلبات بتيجي على البوابة أولاً. قمنا بتركيب “إضافة” (Plugin) على البوابة للتحقق من الـ JWT. البوابة بتتأكد من التوقيع، تاريخ الانتهاء، وكل شي. إذا الطلب سليم، البوابة بتضيف Header خاص للطلب (مثلاً X-Authenticated-User-ID: 123) وبتمرره للخدمة الداخلية.
الخدمات الداخلية (Users, Orders, etc.) بطلت تهتم بالـ JWT نهائياً. هي فقط بتثق بالطلبات اللي جاييتها من البوابة، وبتقرأ الـ Header اللي بقلها مين هو المستخدم. الكود داخل الخدمات صار أنظف وأبسط بكتير.
2. التوجيه الذكي والتجميع (Smart Routing & Aggregation)
الفرونت إند صار يتعامل مع عنوان واحد فقط: api.ourcompany.com.
في إعدادات البوابة، قمنا بتعريف قواعد التوجيه:
- أي طلب بيبدأ بـ
/users، وجهه إلى الخدمة الداخليةhttp://users-service:8080. - أي طلب بيبدأ بـ
/orders، وجهه إلى الخدمة الداخليةhttp://orders-service:8081. - وهكذا…
العميل ما عاد بحاجة يعرف أي تفاصيل عن خدماتنا الداخلية. هذا المبدأ يسمى Reverse Proxy.
نصيحة أبو عمر: من الأنماط المتقدمة والقوية جداً هو “تجميع الطلبات” (Request Aggregation). أحياناً، بدل ما نخلي الفرونت إند يبعت 3 طلبات، ممكن نعمل endpoint واحد على البوابة اسمه مثلاً
/v1/order-details/123. لما البوابة تستقبل طلب على هذا الـ endpoint، هي من ورا الكواليس بتبعت طلب لخدمة الطلبات، وطلب لخدمة المستخدمين، وطلب لخدمة المنتجات، وبتجمع النتائج كلها في رد واحد وبترجعه للعميل. هذا النمط اسمه Backend for Frontend (BFF) وبيريح فريق الواجهة الأمامية بشكل لا يصدق.
3. المراقبة، التسجيل، وتحديد المعدل (Monitoring, Logging & Rate Limiting)
بما أن كل الطلبات بتمر عبر نقطة واحدة، صار عنا مكان مركزي لكل شي:
- التسجيل (Logging): فعلنا إضافة لتسجيل كل طلب ورد في مكان واحد. صار سهل جداً نتابع ونحلل المشاكل.
- المراقبة (Monitoring): ربطنا البوابة مع نظام مراقبة (مثل Prometheus/Grafana) وصرنا نشوف “داشبورد” واحد فيه كل إحصائيات النظام: عدد الطلبات، معدل الأخطاء، سرعة الاستجابة.
- تحديد المعدل (Rate Limiting): عشان نحمي خدماتنا من الاستخدام المفرط أو هجمات الحرمان من الخدمة (DoS)، طبقنا بسهولة قاعدة على البوابة: “كل مستخدم مسموح له يعمل 100 طلب في الدقيقة فقط”. كل هذا بدون ما نكتب سطر كود واحد داخل خدماتنا.
مثال بسيط لإعدادات التوجيه (YAML)
هذا مثال توضيحي جداً لكيف ممكن يبدو ملف إعدادات التوجيه في بوابة مثل Kong أو Traefik. لاحظ السهولة والوضوح:
# api-gateway-routes.yaml
# Route for the Users Service
- name: users-service-route
paths:
- /api/users
# The gateway will forward requests to this internal service
service_url: http://users-service-internal:8080
# Apply the JWT authentication plugin to this route
plugins:
- name: jwt-auth
# Route for the Orders Service
- name: orders-service-route
paths:
- /api/orders
service_url: http://orders-service-internal:8081
plugins:
- name: jwt-auth
# Also apply a rate-limiting plugin
- name: rate-limiting
config:
per_minute: 100
كما ترى، الإعدادات تصريحية (declarative) وسهلة القراءة. نحن “نعلن” عن القواعد، والبوابة تتكفل بالتنفيذ.
الخلاصة: الزبدة من كل هالحكي 😅
بوابة الواجهات البرمجية (API Gateway) ليست مجرد أداة تقنية لطيفة، بل هي ضرورة لا غنى عنها لأي نظام يعتمد على معمارية الخدمات المصغرة ويريد أن ينمو بشكل صحي ومستدام. هي الدرع الواقي، ومنظم السير، وحارس الأمن لنظامك بأكمله.
نقلت عبء المصادقة والتوجيه والمراقبة والأمان من أكتاف كل خدمة على حدة، ووضعته في مكان واحد مركزي وقوي، مما سمح للمطورين بالتركيز على كتابة منطق العمل (Business Logic) الحقيقي لخدماتهم.
نصيحتي الأخيرة لك: إذا كنت تبدأ مشروع خدمات مصغرة، لا تنتظر حتى “توقع الفاس بالراس” مثلنا. ابدأ بالتفكير في الـ API Gateway من اليوم الأول. قد تبدو خطوة إضافية في البداية، لكنها ستوفر عليك شهوراً من الصداع والمعاناة في المستقبل. ابدأ بحل بسيط ومُدار (Cloud-managed) مثل AWS API Gateway أو Azure API Management، أو حل مفتوح المصدر مثل Kong أو Traefik إذا كنت تدير البنية التحتية بنفسك. صدقني، ستشكرني لاحقاً. 😉
