دمج الـ GraphQL مع الـ REST في نظام واحد: متى ولماذا؟

يا هلا بيك يا باشمهندس في عالم تطوير الـ برمجيات (Software Development) الممتع والمعقد في نفس الوقت. تعال نتخيل السيناريو ده مع بعض: أنت شغال في مشروع (Project) كبير، والفرونت إند (Frontend) طالع عينه مع الـ RESTful APIs القديمة؛ مرة طلبات كتير عشان يجيبوا داتا مرتبطة ببعض (Over-fetching أو Under-fetching)، ومرة تانية الباك إند (Backend) حارق دمه في كتابة إندبوينتس (Endpoints) جديدة لكل زرار في الواجهة. من الناحية التانية، الباك إند بتاعك مستقر وشغال زي الفل بـ خدمات مصغرة (Microservices) مبنية على الـ REST API وبتقوم بدورها على أكمل وجه.

السؤال هنا اللي بيطرح نفسه وبيتعب ناس كتير: هل لازم أرمي الـ REST القديم عشان أركب جراف كيو إل (GraphQL)؟ الإجابة ببساطة: لأ خالص! الحل السحري والذكي هو دمج التكنولوجيين مع بعض في نظام واحد (Hybrid Architecture). في المقال ده، هنفهم سوا إزاي نستفيد من مرونة جراف كيو إل للواجهات الأمامية (Frontend Flexibility) مع الحفاظ على قوة واستقرار الـ REST للخدمات الداخلية (Internal REST Services).

إيه هو وجع المبرمج مع الـ REST الـ تقليدي؟

عشان نفهم إحنا ليه بنفكر في الدمج، لازم نعرف إحنا بنشتري دماغنا من إيه أصلاً. الـ REST API هو البطل التاريخي لتطوير الويب، وكلنا بنحبه عشان هو بسيط وبيعتمد على البروتوكول الأساسي للإنترنت (HTTP Methods زي GET, POST, PUT, DELETE).

لكن المشكلة بتظهر لما التطبيق بتاعنا بيكبر والواجهات بتبقى معقدة (Complex User Interfaces). مثلاً، لو عندك صفحة بروفایل مستخدم (User Profile)، وعاوز تعرض بيانات المستخدم، وآخر 5 بوستات ليه، وآخر تعليقات كتبها. في عالم الـ REST التقليدي، قد تحتاج تعمل كده:

// طلبات متعددة من الفرونت إند
GET /api/users/123
GET /api/users/123/posts
GET /api/users/123/comments

ده بيسبب مشكلة مشهورة اسمها الطلبات المتعددة (N+1 Problem أو Multiple Network Requests)، وكمان بيخلينا نجيب بيانات زيادة ملهاش عازة (Over-fetching) تستهلك باقة المستخدمين وتأبطء التطبيق.

ليه ندمج الـ GraphQL مع الـ REST؟ (المعادلة الكسبانة)

الجراف كيو إل (GraphQL) جه عشان يحل المشكلة دي من جذورها؛ بيخلي الفرونت إند يطلب الداتا اللي محتاجها بالحرف (Exact Data Fetching) وفي طلب واحد بس (Single Request). بس استنى.. هل ده معناه إننا نرمي الـ REST اللي صرفنا عليه شهور من الشغل والبناء؟

طبعاً لأ! الـ REST ممتاز جداً للخدمات الداخلية (Backend-to-Backend communication)، ومناسب جداً للـ Caching على مستوى الـ HTTP، ومستقر جداً مع العمليات البسيطة (CRUD Operations). الدمج معناه إننا بنعمل طبقة وسيطة (Gateway أو BFF - Backend for Frontend) بتفهم GraphQL من ناحية الفرونت إند، وتحول الطلبات دي لـ REST Calls تكلم بيها خدمات الباك إند القائمة.

مميزات النهج المدمج (Hybrid Approach):

• مرونة للفرونت إند (Frontend Flexibility): يقدروا يطلبوا الداتا بالشكل اللي هم عايزينه من غير ما يوجعوا دماغ الباك إند.
• حماية الاستثمار الحالي (Preserving Legacy Systems): مش محتاج تعيد كتابة الـ Microservices القديمة اللي شغالة بـ REST وزي الفل.
• تدرج في التحديث (Gradual Migration): تقدر تنقل سيستمك للـ GraphQL خطوة بخطوة من غير ما توقع السيستم كله.

إزاي ننفذ الدمج ده عملياً؟ (Architecture Pattern)

أفضل طريقة لدمج الـ GraphQL مع الـ REST هي بناء خادم وسيط (GraphQL Gateway) أو استخدام نمط الـ BFF (Backend For Frontend). الخادم ده بيلعب دور المترجم.

تعال نبص على مثال عملي بسيط بلغة JavaScript وفريمورك Node.js مع مكتبة Apollo Server وإزاي الجراف كيو إل بينادي على REST API قديم:

const { ApolloServer, gql } = require('apollo-server');
const axios = require('axios');

// 1. تعريف الـ Schema الخاصة بالـ GraphQL
const typeDefs = gql`
  type User {
    id: ID!
    name: String!
    email: String!
    posts: [Post]
  }

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

  type Query {
    user(id: ID!): User
  }
`;

// 2. كتابة الـ Resolvers اللي بتكلم الـ REST API القديم
const resolvers = {
  Query: {
    user: async (_, { id }) => {
      // هنا بنكلم الـ REST API الداخلي
      const response = await axios.get(`https://api.internal-services.com/v1/users/${id}`);
      return response.data;
    },
  },
  User: {
    posts: async (parent) => {
      // استخدام الـ REST API لجلب بيانات مرتبطة
      const response = await axios.get(`https://api.internal-services.com/v1/posts?userId=${parent.id}`);
      return response.data;
    },
  },
};

const server = new ApolloServer({ typeDefs, resolvers });

server.listen().then(({ url }) => {
  console.log(`🚀 GraphQL Gateway شغال هنا: ${url}`);
});

في الكود اللي فوق ده، إحنا عملنا GraphQL Server بيستقبل طلبات الفرونت إند المرنة، وكل ما يجيله طلب، بيقوم ينادي على خدمات الـ REST القديمة (Internal REST APIs) عشان يجمع الداتا ويرجعها للعميل في صورة جراف كيو إل نظيفة ومحددة.

التحديات اللي هتقابلك وإزاي تحلها

زي أي حاجة في التكنولوجيا، الدمج ده ليه ضريبة لازم تكون واخد بالك منها:

• مشكلة الـ N+1 في الجراف كيو إل: لو العميل طلب مستخدمين ومعاهم بوستاتهم، الجراف كيو إل ممكن يعمل طلبات REST كتيرة جداً للباك إند. الحل هنا هو استخدام أداة زي DataLoader عشان تعمل Batching للطلبات دي.
• الـ Caching: التخزين المؤقت في الـ REST أسهل بكتير (عن طريق HTTP Caching) مقارنة بالـ GraphQL اللي دايمًا بيستخدم بوست (POST requests) للـ queries في أغلب الأحيان. الحل هو استخدام استراتيجيات Caching على مستوى الـ Gateway.
• إدارة الأخطاء (Error Handling): التعامل مع الأخطاء القادمة من أكثر من سيرفر REST وإرجاعها بشكل موحد في GraphQL محتاج شوية تركيز وتصميم دقيق للـ Resolvers.

خاتمة ونصیحة أخوية لتطوير مهاراتك

يا صاحبي، مفيش تكنولوجيا واحدة هي "الحل السحري لكل المشاكل" (Silver Bullet). الـ REST قوي جداً ومستقر في الباك إند، والـ GraphQL عبقري ومريح جداً في الفرونت إند والواجهات. الدمج بينهم بيديك قوة التكنولوجيين من غير ما تضطر تهدم اللي بنيته قبل كده.

نصيحتي ليك كـ مبرمج عايز يتطور: متخفش من التجربة. ابدأ اعمل مشروع صغير (Side Project) ادمج فيه الاتنين دول مع بعض، واقرا اكتر عن الـ API Gateways والـ Microservices Architecture. الشغلانة دي مش بس بتخليك تكتب كود، دي بتخليك تفكر كـ مهندس برمجيات فاهم السيستم ماشي إزاي من أول البراوزر لحد الداتابيز.