خدماتي المصغرة كانت فوضى: كيف أنقذتني ‘بوابة الواجهات البرمجية’ (API Gateway) من جحيم الإدارة؟

بتذكر هذيك الليلة منيح، كانت الساعة ٢ بعد منتصف الليل، وأنا قاعد قبال الشاشة عيوني حمر من قلة النوم وريحة القهوة معبية الغرفة. كنا قبلها بأسبوع أطلقنا تحديث كبير لتطبيقنا، اللي كان مبني على معمارية الخدمات المصغرة (Microservices). في البداية، كنا مبسوطين… كل فريق شغال على خدمة لحال، تطوير سريع، استقلالية، وكل الكلام النظري الحلو اللي بنقرأه في الكتب.

لكن في هذيك الليلة، التطبيق صار بطيء فجأة، والمستخدمين بشتكوا. فتحت لوحة المراقبة، وإذا بها انفجار من الأخطاء من كل حدب وصوب. خدمة المستخدمين (Users Service) بترجع خطأ 500، وخدمة الطلبات (Orders Service) بتشتكي من تأخير في الرد من خدمة الدفع (Payments Service). والواجهة الأمامية (Frontend) المسكينة، بتحاول تحكي مع ٥ خدمات مختلفة في نفس الوقت عشان تعرض صفحة واحدة للمستخدم.

صرت أضرب أخماس بأسداس وأحكي لحالي: “يا زلمة، شو هالفوضى؟ كيف بدي أتبع طلب واحد من أول ما يطلع من التطبيق لحد ما يوصل لكل هالخدمات ويرجع؟ ومين المسؤول عن المصادقة؟ كل خدمة بتعملها لحال؟”. حسيت حالي زي اللي بحاول يمسك عشر دجاجات هربانات في ساحة مفتوحة. في هذيك اللحظة، أدركت إن الاستقلالية اللي فرحنا فيها تحولت لجحيم من الإدارة المعقدة. وهنا كانت بداية رحلتي مع المنقذ: بوابة الواجهات البرمجية أو الـ API Gateway.

ما هي بنية الخدمات المصغرة (Microservices) أصلاً؟

قبل ما نغوص في المشاكل والحلول، خلينا نرجع خطوة للوراء. زمان، كنا نبني تطبيقاتنا ككتلة واحدة، أو ما يسمى بالـ “Monolith”. يعني كل شي في مكان واحد: واجهة المستخدم، منطق العمل (Business Logic)، التعامل مع قاعدة البيانات، كله في مشروع برمجي واحد ضخم.

الخدمات المصغرة هي نقيض هالفكرة. الفكرة إنك تكسّر التطبيق الضخم لمجموعة من الخدمات الصغيرة والمستقلة. كل خدمة مسؤولة عن جزئية معينة من وظائف التطبيق. مثلاً:

• خدمة لإدارة حسابات المستخدمين.
• خدمة لعرض المنتجات.
• خدمة لمعالجة الطلبات.
• خدمة لإدارة عمليات الدفع.

كل خدمة الها قاعدة بياناتها الخاصة، وممكن تكون مكتوبة بلغة برمجة مختلفة، وبيتم تطويرها ونشرها (deploy) بشكل مستقل. هاد الأسلوب بيعطينا مرونة وسرعة خرافية في التطوير، بس مثل ما اكتشفت بالطريقة الصعبة، بيخلق تحديات جديدة تماماً.

الفوضى الخلاقة… أو ربما الفوضى فقط! (مشاكل واجهتني شخصياً)

لما الواجهة الأمامية (سواء تطبيق موبايل أو موقع ويب) تحتاج تعرض معلومات للمستخدم، كانت مضطرة تتواصل مباشرة مع كل خدمة من الخدمات المصغرة. هاد الأسلوب المباشر هو أصل كل الشرور، وهاي هي المشاكل اللي صارت معي:

مشكلة تعدد المداخل (Multiple Entry Points)

الواجهة الأمامية كانت لازم تعرف عنوان (URL) كل خدمة من خدماتي. تخيل معي السيناريو: لعرض صفحة “ملفي الشخصي”، التطبيق كان يبعت طلب لـ users.api.com/profile، وطلب ثاني لـ orders.api.com/my-orders، وطلب ثالث لـ reviews.api.com/my-reviews. هاد معناه إن أي تغيير في عنوان أي خدمة، أو تقسيم خدمة لوحدة أصغر، بيتطلب تحديث ونشر تطبيق الموبايل والموقع من جديد. شغلانة ما بتخلص!

كابوس المصادقة والترخيص (Authentication & Authorization)

هاي كانت أكبر وجعة راس. كل خدمة من الخدمات المصغرة لازم تتأكد إنه الطلب اللي جاييها جايي من مستخدم مصرح له. يعني كل خدمة كان فيها كود مكرر للتحقق من الـ Token (زي الـ JWT). ولو اكتشفنا ثغرة أمنية في منطق المصادقة، كنت مضطر أعدّل الكود في ٥ أو ٦ خدمات مختلفة وأعملهم كلهم نشر من جديد. خطر أمني كبير وجهد ضايع.

صعوبة المراقبة والتدوين (Monitoring & Logging)

لما مستخدم يشتكي من مشكلة، كان تتبع رحلة طلبه كابوس. الطلب الواحد ممكن يمر على ٣ أو ٤ خدمات. السجلات (Logs) موزعة بين كل هالخدمات. كنت أفتح ٤ شاشات مختلفة وأحاول أربط سجلات كل خدمة مع بعض باستخدام شي اسمه “Correlation ID”، بس العملية كانت مرهقة وبتاخد وقت طويل جداً.

الـ “Cross-Cutting Concerns” – همّ على القلب

في أمور لازم تتطبق على كل الطلبات اللي بتدخل النظام، مثل:

• تحديد معدل الطلبات (Rate Limiting): عشان نمنع أي مستخدم أو خدمة من إغراق النظام بالطلبات.
• التخزين المؤقت (Caching): عشان نسرّع الاستجابة للطلبات المكررة.
• إنهاء SSL (SSL Termination): فك تشفير طلبات HTTPS عشان الخدمات الداخلية تتعامل مع طلبات HTTP عادية.

تطبيق هاي الأمور في كل خدمة على حدة كان تكراراً مملاً للكود، ومصدر محتمل للأخطاء و”عدم التناسق” بين الخدمات.

المنقذ: بوابة الواجهات البرمجية (API Gateway)

بعد ليلة الأرق هذيك، وبعد بحث وقراءة، وصلت للحل اللي غير طريقة تفكيري بالكامل. الـ API Gateway مش مجرد أداة، هي نمط تصميم (Design Pattern) وُجد خصيصاً لحل فوضى الخدمات المصغرة.

ما هي الـ API Gateway؟ (ببساطة يا جماعة)

تخيل الـ API Gateway زي “البوّاب” أو “موظف الاستقبال” في فندق ضخم. بدل ما الضيف (الـ client) يروح يدور على قسم المحاسبة وقسم خدمة الغرف وقسم المطعم بنفسه، هو بروح بس لموظف الاستقبال، وموظف الاستقبال هو اللي بوجهه وبتواصل مع الأقسام الداخلية بالنيابة عنه.

تقنياً، الـ API Gateway هي خادم (Server) بكون هو نقطة الدخول الوحيدة لكل الطلبات الموجهة للنظام. هي بتقعد بين العميل (Frontend) وبين خدماتك المصغرة. العميل بحكي معها بس، وهي بتتولى مهمة توجيه الطلب للخدمة أو الخدمات الصحيحة في الخلفية.

العميل (Frontend) -> بوابة الـ API -> (خدمة المستخدمين، خدمة الطلبات، …)

كيف حلت الـ API Gateway مشاكلي؟ (الفوائد العملية)

بمجرد ما طبقنا الـ API Gateway، المشاكل اللي ذكرتها فوق بلشت تختفي وحدة ورا التانية:

• توحيد نقطة الدخول: صار العميل ما بعرف إلا عنوان واحد: api.myapp.com. هو بطلب api.myapp.com/profile، والبوابة هي اللي بتعرف إنه هاد الطلب لازم يروح لخدمة المستخدمين وخدمة الطلبات، وبتجمع الردود وبترجعها للعميل في رد واحد. فصل كامل بين العميل والبنية الداخلية.
• مركزية المصادقة والترخيص: كل منطق التحقق من هوية المستخدم وصلاحياته صار موجود في مكان واحد: البوابة. البوابة بتتأكد من الـ Token، وإذا كل شي تمام، بتمرر الطلب للخدمات الداخلية مع معلومات المستخدم. الخدمات الداخلية صارت تثق بأي طلب بيجيها من البوابة. أمان أعلى، وكود أنظف.
• تجميع الطلبات (Request Aggregation): بدل ما تطبيق الموبايل يبعت ٣ طلبات عشان يعرض صفحة واحدة، صار يبعت طلب واحد للبوابة. والبوابة، بذكاء، بتبعت ٣ طلبات للخدمات الداخلية بالتوازي، بتجمع النتائج، وبترجعها مرة واحدة. هاد بقلل من زمن الاستجابة بشكل كبير خصوصاً على شبكات الموبايل البطيئة.
• المراقبة والتحليل في مكان واحد: بما إنه كل الطلبات بتمر من البوابة، صارت هي المكان المثالي لجمع السجلات (Logs) والمقاييس (Metrics). صار تتبع أي طلب سهل جداً.
• تفريغ الحمل (Offloading): كل الـ “Cross-Cutting Concerns” اللي حكينا عنها (Rate Limiting, Caching, SSL) تم نقلها للبوابة. هيك، خدماتنا المصغرة صارت أبسط، ومركزة فقط على منطق العمل الأساسي تبعها. “خلي الخبز للخباز” زي ما بحكوا.

مثال عملي: من الفوضى إلى النظام

عشان أوضح الفكرة، خلينا نشوف مثال بسيط باستخدام بوابة مفتوحة المصدر ومبنية على Node.js اسمها Express Gateway. إعداداتها سهلة وبتنكتب بملف YAML بسيط.

السيناريو قبل البوابة (الفوضى):

تطبيق الموبايل كان لازم يعمل هيك:

// 1. Get user details
GET https://users.myapp.internal/api/v1/users/123

// 2. Get user's recent orders
GET https://orders.myapp.internal/api/v1/orders?userId=123

// 3. Get user's reward points
GET https://rewards.myapp.internal/api/v1/points/123

لاحظ الثلاث طلبات المختلفة لثلاث خدمات مختلفة.

السيناريو بعد البوابة (النظام):

تطبيق الموبايل صار يعمل هيك بس:

// Just one single, beautiful call
GET https://api.myapp.com/dashboard

والسحر كله بصير في ملف إعدادات البوابة. هاي لمحة عن كيف ممكن يكون شكل ملف gateway.config.yml:

http:
  port: 8080

# 1. Define where our backend microservices live
serviceEndpoints:
  userService:
    url: 'https://users.myapp.internal/api/v1'
  ordersService:
    url: 'https://orders.myapp.internal/api/v1'

# 2. Define the public-facing APIs on the gateway
apiEndpoints:
  users:
    host: 'api.myapp.com'
    paths: '/users/:id'
  orders:
    host: 'api.myapp.com'
    paths: '/orders'

# 3. Define the pipelines (the magic glue)
pipelines:
  # Pipeline for the /users endpoint
  users-pipeline:
    apiEndpoints:
      - users
    policies:
      # First, check authentication
      - jwt:
          - action:
              secretOrPublicKey: process.env.JWT_SECRET
              checkCredentialExistence: true
      # Then, proxy the request to the user service
      - proxy:
          - action:
              serviceEndpoint: userService 
              changeOrigin: true
              path: '/users/:id' # Forward to the correct path

  # Pipeline for the /orders endpoint
  orders-pipeline:
    apiEndpoints:
      - orders
    policies:
      # Also check authentication here
      - jwt:
          - action:
              secretOrPublicKey: process.env.JWT_SECRET
              checkCredentialExistence: true
      # Then, proxy to the orders service
      - proxy:
          - action:
              serviceEndpoint: ordersService
              changeOrigin: true

هاد المثال ببين كيف البوابة بتستقبل الطلبات على api.myapp.com، بتطبق سياسة المصادقة (JWT)، وبعدين بتوجه الطلب للخدمة الداخلية الصحيحة. العميل ما عنده أي فكرة عن كل هاي التفاصيل.

نصائح من قلب الميدان (من أبو عمر)

بعد ما اشتغلت على أنظمة بتستخدم بوابات API لسنوات، جمعت شوية نصائح عملية:

• ابدأ ببساطة: مش ضروري تطبق كل ميزات البوابة من أول يوم. ابدأ باستخدامها كـ Reverse Proxy بسيط للمصادقة وتوجيه الطلبات. مع الوقت، ضيف ميزات تانية زي الـ Caching والـ Rate Limiting حسب الحاجة.
• لا تجعلها عنق الزجاجة (Avoid the Bottleneck): بما إن كل الطلبات بتمر من البوابة، لازم تتأكد إنها سريعة جداً ومتاحة دائماً (Highly Available). استخدم عدة نسخ منها (instances) ووزع الحمل بينهم باستخدام Load Balancer.
• لا تضع منطق العمل (Business Logic) فيها: هاي نقطة مهمة جداً. وظيفة البوابة هي التوجيه والحماية والأمور التقنية العامة. إياك أن تكتب فيها كود خاص بحساب أسعار المنتجات أو التحقق من المخزون. هاد مكانة في الخدمة المصغرة المختصة. لو عملت غير هيك، بتكون قاعد بتبني “Monolith” جديد عند مدخل النظام.
• اختر البوابة المناسبة لمشروعك: في حلول جاهزة ومدارة من الشركات الكبرى زي AWS API Gateway أو Azure API Management، وهي بتريحك من همّ الإدارة. وفي حلول مفتوحة المصدر بتنزلها وبتديرها بنفسك زي Kong, Tyk, أو Ocelot (لجماعة الدوت نت). كل خيار إله ميزاته وعيوبه حسب حجم فريقك وميزانيتك وخبرتك.

الخلاصة: من جحيم الإدارة إلى راحة البال 🧘

التحول من الفوضى إلى النظام ما كان بكبسة زر، أخذ وقت وجهد للتعلم والتطبيق. لكن النتيجة كانت تستحق كل دقيقة. بوابة الواجهات البرمجية (API Gateway) ليست مجرد “إضافة جميلة”، بل هي عمود فقري أساسي لأي تطبيق جدي مبني على الخدمات المصغرة.

إذا كنت اليوم بتعاني من نفس الفوضى اللي كنت فيها، وبتحس إن خدماتك المصغرة صارت عبء بدل ما تكون ميزة، فاعرف إنه الحل موجود. ابدأ بالبحث عن الـ API Gateway، جربها على مشروع صغير، وشوف بنفسك كيف رح ترجعلك السيطرة وراحة البال. هي الجسر اللي بوصل بين مرونة الخدمات المصغرة ومتطلبات العالم الحقيقي من أمان وسرعة وسهولة في الإدارة.