GraphQL مقابل REST: كيف تختار نمط الـ API المناسب

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

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

ماذا يفعل كل نمط فعليًا

يُنظّم REST الخادم حول الموارد (resources)، ولكل مورد رابط URL خاص به. تطلب /users/42 و/users/42/orders و/products/9، فيعيد الخادم شكلًا ثابتًا لكل منها. ويتوافق هذا بسلاسة مع طريقة عمل الويب أصلًا: أفعال HTTP (GET وPOST وPUT وDELETE) ورموز الحالة (status codes) والتخزين المؤقت كلها مدمجة. معظم الإنترنت يعمل بنمط REST، ما يعني توفر الأدوات والاستضافة والخبرة في كل مكان.

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

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

أين يتفوق GraphQL

يحل GraphQL مشكلتين تصبحان مكلفتين مع التوسع: الجلب الزائد والجلب الناقص.

• الجلب الزائد (over-fetching) هو أن تعيد نقطة النهاية بيانات أكثر بكثير مما تحتاجه الشاشة، فتُهدر عرض النطاق والبطارية.
• الجلب الناقص (under-fetching) هو مشكلة شاشة الملف الشخصي أعلاه، حيث تفرض شاشة واحدة جولات طلبات متعددة.

يكون GraphQL خيارًا قويًا عندما:

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

بالنسبة لفرق Flutter وReact التي تبني عدة تطبيقات تعتمد على خادم واحد، كثيرًا ما يزيل GraphQL فئة كاملة من المراجعات المتبادلة بين مطوّري الموبايل ومطوّري الـ API.

أين يبقى REST الخيار الافتراضي الذكي

REST ليس الخيار القديم. فبالنسبة لشريحة كبيرة من المنتجات يظل الخيار الأسرع والأرخص والأكثر متانة.

يكون REST خيارًا قويًا عندما:

• يكون الـ API لديك قائمًا على الموارد ويمكن التنبؤ به: لوحة إدارة CRUD قياسية، أو موقع محتوى، أو كتالوج تجارة إلكترونية تقليدي.
• يكون التخزين المؤقت بالغ الأهمية. فتخزين HTTP وشبكات CDN وذاكرة المتصفح تعمل جاهزة مع طلبات REST من نوع GET. أما تخزين نقطة نهاية GraphQL واحدة من نوع POST فأصعب فعليًا.
• تحتاج إلى عرض API عام لأطراف خارجية تعرف مسبقًا أعراف REST وتتوقعها.
• يكون فريقك صغيرًا أو جديدًا على التقنية وتريد أجزاء متحركة أقل. فـ GraphQL يضيف طبقة مخطط، وطبقة محللات (resolvers)، وأنماط أعطال جديدة يجب تعلّمها.
• تتكامل مع بوابات الدفع أو أجهزة POS أو الأنظمة الحكومية في الخليج ومصر التي تأتي بنقاط نهاية REST. تغليفها في GraphQL عمل إضافي قد لا تحتاجه.

وهناك واقع تشغيلي أيضًا: أخطاء REST تُترجم إلى رموز حالة HTTP تفهمها أدوات المراقبة فورًا. بينما يعيد GraphQL عادةً الرمز 200 OK حتى عند الأعطال الجزئية، مع وضع الأخطاء داخل جسم الاستجابة، ما يعني أن أنظمة المراقبة والتنبيه لديك تحتاج إلى إعداد متعمّد.

الأسئلة التي تحسم القرار فعليًا

تجاوز سجال المدوّنات. في المشاريع الحقيقية ينبثق القرار من بضعة أسئلة ملموسة.

كم عدد العملاء الذين يستهلكون هذا الـ API؟

واجهة ويب واحدة تشير إلى خادم واحد نادرًا ما تبرر GraphQL. أما ثلاثة أو أربعة عملاء باحتياجات بيانات متباعدة فكثيرًا ما يبرّرونه.

ما مدى تغيّر شاشاتك؟

الشاشات الثابتة المتوقعة تميل نحو REST. والشاشات المركّبة كثيرة إعادة التصميم تميل نحو GraphQL.

ما أهمية التخزين المؤقت والتسليم عبر CDN؟

الأحمال كثيرة القراءة والصديقة للتخزين (الكتالوجات والمقالات والمواقع التسويقية) تميل نحو REST. وبيانات التطبيقات المخصّصة وكثيرة الكتابة تميل نحو GraphQL.

من سيصون هذا بعد عامين؟

الفريق الصغير أو تسليم العمل من وكالة كثيرًا ما يكون أفضل مع مساحة REST الأصغر. أما فريق منتج متفرّغ فيستطيع استيعاب تعقيد GraphQL الإضافي وجني سرعته.

هل هذا داخلي أم عام؟

الـ APIs العامة الموجّهة للشركاء تكسب عادةً بفضل ألفة REST الشاملة. أما APIs المنتجات الداخلية سريعة الحركة فهي حيث يتألق GraphQL.

لست مضطرًا لاختيار واحد فقط

الإجابة الأكثر عملية كثيرًا ما تكون "كلاهما، كلٌّ في موضعه الصحيح". من الأنماط الشائعة التي نستخدمها: REST للتكاملات العامة والخارجية الثابتة، وGraphQL لسطح المنتج الغني متعدد العملاء. وبعض الفرق تضع طبقة GraphQL أمام خدمات REST قائمة لتمنح مطوّري الواجهة الأمامية عقدًا نظيفًا موحّدًا دون إعادة بناء الخادم.

ما ينبغي تجنّبه هو الاختيار بناءً على ما هو رائج. فتبني GraphQL بإهمال يخلق مشكلات أداء استعلام مكلفة (مشكلة N+1 الكلاسيكية) وثغرات أمنية إذا أمكن للعملاء طلب بيانات عميقة بلا حدود. وتبني REST بإهمال يتشعّب إلى عشرات نقاط النهاية غير المتسقة التي لا يوثّقها أحد. تصميم الـ API الجيد، لا التسمية، هو ما يحدد ما إذا كان خادمك سيتقادم بشكل جيد.

أهم النقاط

• REST مقابل GraphQL قرار ملاءمة لا ترتيب جودة. فلكلٍّ منهما حالات يتفوق فيها.
• اختر GraphQL للعملاء المتعددين والشاشات المركّبة الغنية بالبيانات والواجهات سريعة الحركة التي تحتاج عقدًا مرنًا محدد الأنواع.
• اختر REST للـ APIs القائمة على الموارد، والأحمال كثيرة القراءة والتخزين، والـ APIs العامة، والفرق الأصغر التي تقدّر البساطة.
• التخزين المؤقت والمراقبة نقطتا قوة هادئتان لـ REST؛ خطّط لهما بتعمّد إن اخترت GraphQL.
• البنى الهجينة خيار صحيح. استخدم كل نمط حيث يستحق مكانه بدل توحيد الكل على واحد.

نمط الـ API المناسب يعتمد على عملائك وخريطة طريقك ومن سيصونه العام المقبل، لا على ما فاز في آخر محاضرة مؤتمر. في SummationWorks نصمم الخوادم والـ APIs لمنتجات الويب والموبايل عبر الخليج ومصر وما بعدهما، ونتخذ هذا القرار بناءً على قيودك الحقيقية. تعرّف على خدماتنا، أو اطّلع على أعمالنا، أو تواصل معنا لنناقش البنية المناسبة لمنتجك.