كانت واجهاتنا شبكة عنكبوت: كيف أنقذ نمط ‘بوابة الواجهة البرمجية’ (API Gateway) مشروعنا من الفوضى؟

السلام عليكم يا جماعة الخير،

أنا أبو عمر، وبدي أحكيلكم قصة صارت معي قبل كم سنة. كنا شغالين على مشروع ضخم، منصة تجارة إلكترونية جديدة كليًا. الفريق كان متحمس جدًا، وقررنا نتبنى معمارية الخدمات المصغرة (Microservices). قلنا “خلص، بدنا شغل مرتب ومستقبلي”. كل فريق استلم مسؤولية خدمة معينة: فريق لخدمة المنتجات، وفريق لخدمة المستخدمين، وفريق للتقييمات، وفريق للمخزون… وهكذا. الأمور كانت تبدو وردية في البداية، كل خدمة مستقلة، وكل فريق “راسه براس” وبيشتغل لحاله.

الفوضى بدأت تظهر لما فريق الواجهة الأمامية (Frontend) بدأ يشتغل. أذكر يومها إجاني المهندس المسؤول عن الواجهة، وجهه أحمر من العصبية، وقال لي: “يا أبو عمر، مش معقول هيك! عشان أعرض صفحة منتج واحدة، لازم أعمل 5 استدعاءات (requests) مختلفة! مرة لخدمة المنتجات عشان أجيب تفاصيل المنتج، ومرة لخدمة التقييمات عشان أجيب تقييمات الناس، ومرة لخدمة المخزون عشان أشوف إذا القطعة متوفرة، ومرة لخدمة المستخدمين عشان أعرف إذا المستخدم عامل ‘لايك’ للمنتج، وكمان استدعاء عشان أجيب المنتجات المقترحة! الواجهة صارت زي شبكة العنكبوت، وكل خيط ممكن ينقطع بأي لحظة!”.

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

ما هي المشكلة بالضبط؟ تشريح فوضى الخدمات المصغرة

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

• الثرثرة المفرطة (Chatty Client): العميل (الواجهة) يضطر لإجراء العديد من الاستدعاءات الشبكية للحصول على كافة البيانات التي يحتاجها لعرض شاشة واحدة. هذا يؤدي إلى بطء في التحميل وتجربة مستخدم سيئة، خاصة على شبكات الجوال البطيئة.
• الاقتران الوثيق (Tight Coupling): الواجهة الأمامية تصبح على دراية كاملة بالهيكل الداخلي للنظام. هي تعرف عناوين كل خدمة، ونقاط النهاية (endpoints) الخاصة بها. إذا قرر فريق خدمة المنتجات إعادة هيكلة الـ API الخاص به (مثلاً تغيير /products/123 إلى /catalog/items/123)، فإن الواجهة الأمامية ستتعطل مباشرة.
• تعقيد المصادقة والترخيص (Authentication & Authorization): كيف ستتعامل الواجهة الأمامية مع المصادقة؟ هل سترسل الـ Token لكل خدمة على حدة؟ وماذا لو كانت كل خدمة تستخدم آلية مختلفة قليلاً؟ هذا يضع عبئًا أمنيًا ومنطقيًا كبيرًا على العميل.
• تعدد البروتوكولات (Protocol Diversity): قد تستخدم بعض الخدمات بروتوكول REST API المعتاد، بينما قد تستخدم خدمات أخرى تتطلب أداءً عاليًا بروتوكولات مثل gRPC. إجبار الواجهة الأمامية على فهم والتعامل مع كل هذه البروتوكولات هو أمر غير عملي.

الحل السحري: تقديم نمط بوابة الواجهة البرمجية (API Gateway)

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

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

كيف يعمل الـ API Gateway؟ (الميكانيكية الداخلية)

البوابة ليست مجرد “بروكسي” غبي. إنها طبقة ذكية تقوم بالعديد من المهام الحيوية، مما يريح الواجهات الأمامية والخدمات الخلفية على حد سواء. أهم وظائفها:

1. توجيه الطلبات (Request Routing)

أبسط وظيفة للبوابة هي توجيه الطلبات. عندما يصل طلب مثل /api/users/profile، تعرف البوابة أن هذا الطلب يجب أن يذهب إلى “خدمة المستخدمين”. وعندما يصل طلب /api/orders، يتم توجيهه إلى “خدمة الطلبات”. هذا يخفي تفاصيل مواقع الخدمات عن العميل.

2. تجميع الطلبات (Request Aggregation/Composition)

وهذه هي الوظيفة التي أنقذتنا. بدلًا من أن تقوم الواجهة الأمامية بعمل 5 استدعاءات لصفحة المنتج، هي الآن تقوم باستدعاء واحد فقط إلى البوابة، مثلاً: GET /api/product-details/123.
البوابة بدورها، تقوم داخليًا بالآتي:

1. تستدعي خدمة المنتجات للحصول على تفاصيل المنتج.
2. تستدعي خدمة التقييمات للحصول على التقييمات.
3. تستدعي خدمة المخزون للتحقق من التوفر.

بعد أن تحصل على جميع الردود، تقوم بتجميعها في كائن JSON واحد مرتب ومنظم، ثم تعيده إلى الواجهة الأمامية. لقد تحولت “ثرثرة” الواجهة إلى محادثة واحدة هادئة ومنظمة.

3. تفريغ المسؤوليات (Cross-Cutting Concerns Offloading)

الـ API Gateway هو المكان المثالي لوضع كل المنطق المشترك بين الخدمات، مثل:

• المصادقة والترخيص (Authentication/Authorization): البوابة تتحقق من هوية المستخدم وصلاحياته مرة واحدة. إذا كان الطلب صالحًا، يمكنها تمريره إلى الخدمات الداخلية كطلب “موثوق”، ربما مع إضافة معلومات المستخدم في الـ Headers.
• تحديد سقف الطلبات (Rate Limiting & Throttling): لحماية خدماتك من الاستخدام المفرط أو هجمات الحرمان من الخدمة (DoS)، يمكنك تطبيق قواعد تحديد سقف الطلبات على مستوى البوابة.
• التخزين المؤقت (Caching): الطلبات التي لا تتغير بياناتها كثيرًا (مثل قائمة فئات المنتجات) يمكن تخزينها مؤقتًا على مستوى البوابة لتقليل الحمل على الخدمات الخلفية وتحسين سرعة الاستجابة.
• التسجيل والمراقبة (Logging & Monitoring): توفر البوابة نقطة مركزية لتسجيل كل الطلبات الواردة إلى النظام، مما يسهل تتبع المشاكل ومراقبة الأداء.

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

دعونا نرى كيف تغير الكود الخاص بالواجهة الأمامية بشكل جذري.

السيناريو قبل الـ API Gateway (شبكة العنكبوت)

كان كود الجافاسكربت في الواجهة الأمامية يبدو هكذا:

// قبل الـ API Gateway - الكود المعقد في الواجهة الأمامية
async function getProductDetails(productId) {
  try {
    // استدعاءات متوازية لعدة خدمات بأسماء نطاق مختلفة
    const productPromise = fetch(`https://products.api.example.com/products/${productId}`);
    const reviewsPromise = fetch(`https://reviews.api.example.com/reviews?productId=${productId}`);
    const stockPromise = fetch(`https://inventory.api.example.com/stock-levels/${productId}`);

    const [productRes, reviewsRes, stockRes] = await Promise.all([
      productPromise,
      reviewsPromise,
      stockPromise
    ]);

    // معالجة كل استجابة على حدة
    const product = await productRes.json();
    const reviews = await reviewsRes.json();
    const stock = await stockRes.json();

    // تجميع البيانات يدويًا في الواجهة
    return { ...product.data, reviews: reviews.data, stock: stock.data };
  } catch (error) {
    console.error("فشلت عملية جلب تفاصيل المنتج:", error);
    // معالجة الأخطاء من عدة مصادر محتملة
  }
}

لاحظ التعقيد: عدة عناوين API، معالجة أخطاء معقدة، وتجميع يدوي للبيانات.

السيناريو بعد الـ API Gateway (الطريق السريع)

بعد تطبيق البوابة، أصبح الكود في الواجهة الأمامية نظيفًا وبسيطًا بشكل لا يصدق:

// بعد الـ API Gateway - الكود النظيف والبسيط
async function getProductDetails(productId) {
  try {
    // استدعاء واحد فقط لنقطة نهاية موحدة
    const response = await fetch(`https://api.example.com/v1/product-details/${productId}`);
    const productDetails = await response.json();
    return productDetails;
  } catch (error) {
    console.error("فشلت عملية جلب تفاصيل المنتج:", error);
    // معالجة الأخطاء أصبحت أبسط بكثير
  }
}

كل التعقيد انتقل من الواجهة الأمامية إلى الـ API Gateway، وهذا هو مكانه الصحيح. الواجهة الأمامية الآن لا تعرف ولا تهتم بوجود خدمات مصغرة متعددة في الخلفية.

نصائح من خبرة أبو عمر

الـ API Gateway أداة قوية جدًا، ولكن “كل إشي بزيد عن حده بنقلب ضده”. إليك بعض النصائح من تجربتي:

• ابدأ ببساطة: لا تهرع لتطبيق API Gateway إذا كان لديك تطبيق بسيط (Monolith) أو خدمتين فقط. هذا النمط يضيء نجمه في البيئات المعقدة التي تحتوي على 3 خدمات مصغرة فما فوق.
• احذر من أن تصبح البوابة عنق الزجاجة (Bottleneck): بما أن كل الطلبات تمر عبر البوابة، يجب أن تكون عالية الأداء، قابلة للتوسع (scalable)، وذات إتاحة عالية (highly available). أي فشل في البوابة يعني فشل النظام بأكمله.
• فكر في نمط “الواجهة الخلفية للواجهة الأمامية” (BFF): أحيانًا، احتياجات تطبيق الجوال تختلف عن احتياجات تطبيق الويب. في هذه الحالة، قد يكون من المفيد إنشاء بوابة مخصصة لكل نوع من الواجهات (Mobile Gateway, Web Gateway). هذا النمط يسمى BFF وهو امتداد طبيعي لفكرة الـ API Gateway.
• اختر أداتك بحكمة: يوجد العديد من الحلول الجاهزة والمفتوحة المصدر لإنشاء بوابات API، مثل Kong, Tyk, Ocelot (لمطوري .NET)، و Spring Cloud Gateway (لمطوري Java)، بالإضافة إلى الخدمات السحابية المدارة مثل AWS API Gateway و Azure API Management. اختر الأداة التي تناسب تقنيات فريقك وحجم مشروعك. “الشغل المرتب بيبدأ من اختيار العدّة الصح”.

الخلاصة: من شبكة عنكبوت إلى طريق سريع منظم

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

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