واجهاتنا البرمجية كانت تثرثر بلا توقف: كيف أنقذنا ‘GraphQL’ من جحيم الطلبات المتعددة والبيانات الزائدة؟

يا أهلاً وسهلاً فيكم يا جماعة الخير. معكم أخوكم أبو عمر.

بتذكر قبل كم سنة، كنا شغالين على لوحة تحكم ضخمة ومعقدة لأحد المشاريع. تطبيق ويب من اللي قلبك يحبه، فيه كل شي: إحصائيات، رسوم بيانية، قوائم مستخدمين، رسائل، إشعارات… كل ما يخطر على بالك. الفريق كان متحمس، والتصاميم كانت “آخر طراز”، زي ما بنحكي.

لكن لما بلّشنا نربط الواجهة الأمامية (Front-end) مع الواجهة الخلفية (Back-end) عن طريق REST APIs، بدأت الكوابيس. فتحتُ الـ Network tab في أدوات المطور بالمتصفح، وإذ الشاشة ولّعت قدامي زي شجرة عيد الميلاد! عشرات الطلبات (requests) رايحة جاي مع كل نقرة، وكل طلب برجع “كوم” بيانات ما إلنا لزوم فيه. الصفحة كانت بطيئة، خصوصاً على الإنترنت الضعيف، وصارت الشكاوى تزيد من الفريق ومن العملاء التجريبيين. وقتها وقفت مع الشباب وقلت لهم: “يا جماعة الخير، شو هالحكي؟ الواجهات تبعتنا قاعدة ‘بِتْثرْثِر’ مع السيرفر بدون أي لزوم، وإحنا قاعدين بنغرق في بحر من البيانات الزايدة!”.

هذه الحادثة كانت نقطة التحول اللي خلتنا نبحث عن حل جذري، وكان الحل اسمه GraphQL.

ما هي حكاية “الثرثرة” و”البيانات الزائدة”؟

قبل ما نحكي عن المنقذ GraphQL، خلونا نفهم أصل المشكلة اللي واجهتنا مع بنية REST API التقليدية في التطبيقات المعقدة. المشكلة بتتلخص في نقطتين أساسيتين:

جحيم الطلبات المتعددة (Multiple Requests Hell)

تخيل معي إنك بدك تبني صفحة بروفايل لمستخدم. في هاي الصفحة، أنت بحاجة تعرض:

• معلومات المستخدم الأساسية (الاسم، الصورة الشخصية).
• آخر 3 مقالات كتبها المستخدم.
• قائمة بآخر 5 متابعين له.

باستخدام REST API التقليدي، فريق الواجهة الأمامية سيضطر لإرسال عدة طلبات للحصول على كل هذه المعلومات:

1. GET /api/users/123 لجلب معلومات المستخدم.
2. GET /api/users/123/posts?limit=3 لجلب آخر 3 مقالات.
3. GET /api/users/123/followers?limit=5 لجلب آخر 5 متابعين.

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

مشكلة البيانات الزائدة (Over-fetching)

الآن، لننظر إلى الطلب الأول: GET /api/users/123. في الغالب، هذا الـ endpoint مصمم ليكون عاماً، وبالتالي سيعيد لك كل معلومات المستخدم الموجودة في قاعدة البيانات:

{
  "id": 123,
  "username": "abu_omar_dev",
  "firstName": "عمر",
  "lastName": "أحمد",
  "email": "user@example.com",
  "avatar": "url_to_avatar.jpg",
  "bio": "مبرمج ومطور...",
  "createdAt": "2021-01-15T10:30:00Z",
  "updatedAt": "2023-05-20T12:00:00Z",
  "lastLoginIp": "192.168.1.1",
  "isActive": true
  // ... وغيرها الكثير من الحقول
}

في صفحة البروفايل، كل ما كنت أحتاجه هو الاسم والصورة الشخصية (firstName, avatar). لكن الخادم أرسل لي “شوال” بيانات كامل لا يلزمني، مثل تاريخ الإنشاء، آخر آي بي، وغيرها. هذا هو الـ “Over-fetching”، إهدار واضح وصريح لموارد الشبكة والخادم، ويجعل التطبيق أبطأ بلا أي داعٍ.

لقاءنا الأول مع GraphQL: كيف غيّر قواعد اللعبة؟

وسط هذا الجحيم، بدأنا البحث عن بدائل. سمعنا عن تقنية جديدة وقتها اسمها GraphQL، من تطوير فيسبوك. القصة وما فيها، GraphQL هي ليست مكتبة أو إطار عمل، بل هي “لغة استعلام” (Query Language) للـ API.

الفكرة عبقرية وبسيطة: بدلاً من أن يكون للخادم عدة نقاط وصول (endpoints) ثابتة ومحددة مسبقاً (مثل /users, /posts)، يصبح لديك نقطة وصول واحدة فقط (عادة /graphql). والواجهة الأمامية (العميل) هي التي تحدد بالضبط البيانات التي تحتاجها في كل طلب، بالحقل والدقة.

مبدأ العمل: أنت تطلب، الخادم يُجيب على قد الطلب. لا زيادة ولا نقصان.

هذا المبدأ يحل المشكلتين السابقتين من جذورهما. لا حاجة لطلبات متعددة، ولا وجود للبيانات الزائدة.

لنُترجم الحكي لأكواد: REST مقابل GraphQL

دعونا نعود لنفس سيناريو صفحة البروفايل لنرى الفرق عملياً.

السيناريو مع REST (الطريقة القديمة)

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

السيناريو مع GraphQL (الطريقة الحديثة)

مع GraphQL، نرسل طلباً واحداً فقط إلى نقطة الوصول /graphql. هذا الطلب (الذي يسمى Query) يصف بالضبط ما نريده:

query GetUserProfilePage {
  user(id: "123") {
    firstName
    avatar
    
    posts(limit: 3) {
      title
      slug
    }
    
    followers(limit: 5) {
      name
      avatar
    }
  }
}

والأجمل من ذلك، هو شكل الاستجابة التي تأتي من الخادم. استجابة واحدة بصيغة JSON، تطابق تماماً هيكل الطلب الذي أرسلناه:

{
  "data": {
    "user": {
      "firstName": "عمر",
      "avatar": "url_to_avatar.jpg",
      "posts": [
        { "title": "مقالتي الأولى", "slug": "my-first-post" },
        { "title": "مقالتي الثانية", "slug": "my-second-post" },
        { "title": "مقالتي الثالثة", "slug": "my-third-post" }
      ],
      "followers": [
        { "name": "متابع 1", "avatar": "avatar1.jpg" },
        { "name": "متابع 2", "avatar": "avatar2.jpg" },
        // ...
      ]
    }
  }
}

لاحظ الجمال هنا: طلب واحد، استجابة واحدة، لا بيانات زائدة، ولا بيانات ناقصة. كل ما نحتاجه بالضبط. لقد تحولت “الثرثرة” العشوائية إلى حوار منظم وهادف.

نصائح من قلب الميدان

بعد سنوات من استخدام GraphQL في مشاريع مختلفة، جمعت لكم بعض النصائح العملية من تجربتي الشخصية:

متى تستخدم GraphQL؟

GraphQL ليست حلاً سحرياً لكل المشاكل. REST API ما زالت ممتازة وبسيطة للمهام الصغيرة والمباشرة. استخدم GraphQL عندما:

• تطبيقاتك تحتوي على واجهات مستخدم معقدة تتطلب بيانات من مصادر متعددة في شاشة واحدة.
• تستهدف الهواتف المحمولة بشكل أساسي، حيث كل بايت من البيانات يفرق في الأداء وتكلفة الإنترنت.
• لديك عدة واجهات (ويب، iOS، أندرويد) تستهلك نفس الـ API ولكن باحتياجات بيانات مختلفة.
• تعمل في بيئة Microservices، حيث يمكن لـ GraphQL أن تعمل كـ “بوابة” (API Gateway) توحد كل الخدمات خلف واجهة واحدة متناسقة.

لا ترمِ REST API القديم!

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

فكّر بالمخطط (Schema) أولاً

قلب أي خادم GraphQL هو الـ “Schema” (المخطط). المخطط هو العقد الرسمي بين الواجهة الأمامية والخلفية، يصف كل أنواع البيانات المتاحة والعمليات التي يمكن إجراؤها. استثمر وقتاً كافياً في تصميم مخطط جيد وواضح وقابل للتوسع. مخطط جيد يعني تجربة تطوير أفضل بكثير للجميع.

الخلاصة: من الثرثرة إلى الحوار الهادف 🎯

في قصتنا، GraphQL لم تكن مجرد تقنية جديدة، بل كانت تغييراً في طريقة التفكير. لقد أجبرتنا على التفكير من منظور الواجهة الأمامية واحتياجاتها أولاً. حولنا العلاقة بين العميل والخادم من سلسلة أوامر صارمة (REST) إلى حوار مرن وذكي، حيث يطلب العميل ما يريد بالضبط، ويستجيب الخادم بكفاءة.

النتيجة كانت تطبيقات أسرع، استهلاك أقل للبيانات، وتجربة تطوير أكثر سلاسة وإنتاجية لفريقنا. لم نعد نسمع شكاوى عن بطء التحميل، وعادت الابتسامة لوجوه المطورين والمستخدمين على حد سواء.

نصيحتي الأخيرة لك: لا تخف من تجربة التقنيات الجديدة التي تحل مشاكل حقيقية تواجهك. قد تكون GraphQL هي ما تحتاجه بالضبط لتصمت “ثرثرة” واجهاتك البرمجية. يلا شدوا حيلكم يا جماعة، وبالتوفيق في مشاريعكم!