واجهاتي البرمجية كانت ترسل جبلاً من البيانات: كيف أنقذني GraphQL من جحيم الاستجابات المتضخمة؟

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

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

قعدت مع حالي، صرت أحلل وأفصفص المشكلة. الكود على التطبيق نفسه كان نظيف ومحسن قدر الإمكان. المشكلة ما كانت من التطبيق، المشكلة كانت من “الخلفية” (Backend). فتحت أدوات المطورين عشان أراقب طلبات الشبكة (Network Requests)، وهون كانت الصدمة. عشان أعرض اسم المنتج وسعره وصورته في القائمة، كنت أطلب من الـ API بيانات كل المنتجات. والـ API، الله يسامحه، كان يرجعلي “شوال” كامل من البيانات لكل منتج: الـ ID، والاسم، والسعر، والوصف الكامل المكوّن من 500 كلمة، وتاريخ الإضافة، وتاريخ التعديل، وقائمة الموردين، وتقييمات المستخدمين… جبل كامل من المعلومات وأنا كل اللي لازمني ثلاث شغلات بس!

هذا هو بالضبط ما يسمى بـ “جحيم الاستجابات المتضخمة” أو الـ Over-fetching. كنت كأني بطلب من النادل كاسة مي، فبجيبلي خزان مي كامل. في هذيك اللحظة، أدركت إن طريقة بناء الـ APIs التقليدية باستخدام REST لازم تتغير. ومن هنا بدأت رحلتي مع منقذي: GraphQL.

ما هو الجحيم الذي كنت أعيشه؟ (مشكلة الـ Over-fetching مع REST)

خلوني أبسّط لكم القصة أكثر. في عالم واجهات REST البرمجية، اللي أغلبنا تعلمناه وبدأنا فيه، الخادم (Server) هو اللي بقرر شكل وحجم البيانات اللي رح ترجع للعميل (Client). عندك نقطة وصول (Endpoint) محددة، زي /api/users/1، وهذه النقطة مبرمجة عشان ترجع كل معلومات المستخدم رقم 1.

المشكلة بتظهر لما يكون عندك عملاء مختلفين باحتياجات مختلفة. مثلاً:

• واجهة الويب: قد تحتاج لعرض اسم المستخدم وصورته وبريده الإلكتروني.
• تطبيق الجوال: قد يحتاج فقط لاسم المستخدم وصورته.
• لوحة التحكم للمدير: تحتاج لكل شيء: الاسم، العنوان، تاريخ التسجيل، آخر نشاط، قائمة الطلبات… إلخ.

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

مثال عملي على المعاناة

تخيل أنك تطلب بيانات مستخدم من واجهة REST تقليدية عبر الطلب GET /api/users/123. قد تبدو الاستجابة هكذا:

{
  "id": "123",
  "username": "abu_omar_dev",
  "email": "abu.omar@example.com",
  "firstName": "عمر",
  "lastName": "الفلسطيني",
  "bio": "مبرمج ومطور برمجيات خبير في الذكاء الاصطناعي...",
  "avatarUrl": "https://example.com/avatar.jpg",
  "registeredAt": "2018-01-15T10:30:00Z",
  "lastLogin": "2023-10-26T18:00:00Z",
  "address": {
    "street": "شارع يافا",
    "city": "القدس",
    "country": "فلسطين"
  },
  "posts": [
    { "id": "p1", "title": "مقدمة في الذكاء الاصطناعي" },
    { "id": "p2", "title": "لماذا أستخدم لينكس" }
  ],
  "followersCount": 5000,
  "followingCount": 150
}

الآن، تخيل أن كل ما تحتاجه في صفحة معينة هو عرض صورة المستخدم واسمه (avatarUrl و username). انظر إلى كمية البيانات الهائلة التي أُجبرت على تحميلها دون أي فائدة. هذا هو الـ Over-fetching بعينه. إنه يستهلك باقة الإنترنت لدى المستخدم، يبطئ التطبيق، ويزيد العبء على الخادم.

الضوء في آخر النفق: أول لقاء لي مع GraphQL

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

GraphQL، التي طورتها فيسبوك (الآن Meta) لحل مشاكل تطبيقاتها الضخمة، هي ليست مكتبة برمجية أو إطار عمل، بل هي “لغة استعلام” (Query Language) للواجهات البرمجية. الفكرة عبقرية في بساطتها: بدلاً من أن يقرر الخادم ما سيرسله، العميل هو من يطلب بالضبط ما يحتاجه، لا أكثر ولا أقل.

انقلبت الآية تماماً. المقود الآن في يد المطور الأمامي (Frontend Developer). الخادم يعرض قائمة بالبيانات المتاحة، والعميل يختار منها ما يلزمه فقط.

كيف يعمل السحر؟ تشريح استعلام GraphQL

لنعد إلى مثال المستخدم السابق. بدلاً من طلب GET /api/users/123، مع GraphQL أنت ترسل طلب POST إلى نقطة وصول واحدة فقط (غالباً /graphql) وتحتوي على “استعلام” (Query) يصف البيانات التي تريدها.

إذا كنت أريد فقط اسم المستخدم وصورته، سأكتب الاستعلام التالي:

query GetUserProfile {
  user(id: "123") {
    username
    avatarUrl
  }
}

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

{
  "data": {
    "user": {
      "username": "abu_omar_dev",
      "avatarUrl": "https://example.com/avatar.jpg"
    }
  }
}

لاحظ الجمال هنا! طلبت حقلين، حصلت على حقلين. لا بيانات ضائعة، لا استجابات متضخمة. لو احتجت في شاشة أخرى البريد الإلكتروني أيضاً، كل ما علي فعله هو تعديل الاستعلام:

query GetUserForSettings {
  user(id: "123") {
    username
    avatarUrl
    email
  }
}

التحكم أصبح كاملاً في يدي. يا الله شو كان شعور مريح!

نصيحة من خبرة أبو عمر: عندما تبدأ مع GraphQL، ركز على فهم أن الاستجابة هي مرآة للاستعلام. هذا المفهوم البسيط هو مفتاح فهم قوتها. ما تطلبه هو بالضبط ما ستحصل عليه.

ما هو أكثر من مجرد “دايت” للبيانات؟

حل مشكلة الـ Over-fetching كان السبب الرئيسي الذي جذبني لـ GraphQL، لكني اكتشفت مع الوقت أن لديها مزايا أخرى غيرت طريقة عملي تماماً.

وداعاً للـ Under-fetching وطلبات الشبكة المتعددة

الـ Under-fetching هو الوجه الآخر للعملة. يحدث هذا عندما لا توفر نقطة الوصول (Endpoint) كل البيانات التي تحتاجها، فتضطر إلى إرسال طلبات متعددة لجمع المعلومات. مثلاً، لعرض صفحة ملف شخصي مع قائمة منشوراته:

1. أرسل طلب لـ /api/users/123 للحصول على معلومات المستخدم.
2. بعد وصول الاستجابة، أرسل طلب آخر لـ /api/users/123/posts للحصول على منشوراته.
3. إذا أردت عرض التعليقات على كل منشور، قد تضطر لإرسال طلب لكل منشور: /api/posts/p1/comments، /api/posts/p2/comments… كارثة!

هذه “الشلالات” من الطلبات تقتل أداء التطبيق. مع GraphQL، يمكنك طلب كل هذه البيانات المتداخلة في طلب واحد فقط.

query GetUserProfileWithPosts {
  user(id: "123") {
    username
    avatarUrl
    posts(first: 5) {
      title
      content
      comments(first: 3) {
        text
        author {
          username
        }
      }
    }
  }
}

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

نظام أنواع قوي (Strongly Typed Schema)

أحد أروع جوانب GraphQL هو الـ “Schema” أو المخطط. قبل كتابة أي كود لحل الاستعلامات، أنت تقوم بتعريف أنواع البيانات المتاحة والعلاقات بينها باستخدام لغة تعريف المخطط (Schema Definition Language – SDL). هذا المخطط يعمل كـ “عقد” بين الواجهة الأمامية والخلفية.

مثال بسيط للمخطط:

type User {
  id: ID!
  username: String!
  email: String
  posts: [Post!]
}

type Post {
  id: ID!
  title: String!
  content: String
}

# النقطة التي تبدأ منها كل الاستعلامات
type Query {
  user(id: ID!): User
  posts: [Post!]
}

هذا المخطط ليس مجرد توثيق، بل هو جزء حي من الـ API. بسببه، تحصل على مزايا خرافية:

• توثيق ذاتي: الواجهة توثّق نفسها بنفسها. يمكنك استكشاف كل البيانات المتاحة مباشرة.
• التحقق من صحة الطلبات: إذا حاول العميل طلب حقل غير موجود، الخادم سيرفض الطلب فوراً برسالة خطأ واضحة.
• إكمال تلقائي (Autocomplete): أدوات مثل GraphiQL أو Apollo Studio تمنحك إكمالاً تلقائياً جبّاراً أثناء كتابة الاستعلامات.

نصائح من “الختيار”: متى تستخدم GraphQL (ومتى لا)

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

متى تكون GraphQL خياراً ممتازاً؟

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

متى قد لا تكون الخيار الأفضل؟

• التطبيقات البسيطة جداً: إذا كان تطبيقك مجرد واجهات CRUD بسيطة (Create, Read, Update, Delete) على مورد واحد، فإن بساطة REST قد تكون كافية وأسرع في التنفيذ.
• الاعتماد الكبير على التخزين المؤقت لـ HTTP: واجهات REST تستفيد بشكل طبيعي من آليات التخزين المؤقت (Caching) للمتصفحات والشبكات. تحقيق نفس المستوى من الكفاءة في GraphQL يتطلب عملاً إضافياً (وإن كان ممكناً تماماً مع مكتبات مثل Apollo Client).
• فريق غير مستعد: تتطلب GraphQL منحنى تعلمياً، خاصة في جانب الخادم. إذا كان فريقك مضغوطاً بالوقت وغير مستعد لتعلم مفاهيم جديدة، فالتمسك بـ REST قد يكون قراراً عملياً على المدى القصير.

الخلاصة والنصيحة الأخيرة 🚀

رحلتي من جحيم الـ Over-fetching مع REST إلى نعيم التحكم الدقيق مع GraphQL كانت نقطة تحول في مسيرتي كمطور. GraphQL أعادت السلطة إلى العميل (الواجهة الأمامية)، مما سمح لي ببناء تطبيقات أسرع وأكثر كفاءة وقابلية للصيانة.

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

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

والله ولي التوفيق.