GraphQL هي اللغة التي انتظرها وكلاء الذكاء الاصطناعي

صُمِّمت GraphQL في 2015 لتسريع عمل الواجهة الأمامية. وتبيّن أنها واجهة متفوقة لآلات تطرح أسئلة ذكية.

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

وتترك هذه الحجة السؤال التالي الذي لا يطرحه أحد تقريباً بعد وينبغي أن يطرحه الجميع: أي نوع من واجهات البرمجة ينبغي بناؤه؟

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

كأن Facebook بنت بالمصادفة في 2015 لغة استعلام عصر الوكلاء، وأمضى القطاع العقد التالي في استخدامها أساساً لجعل تطبيقات React أكثر راحة قليلاً. وهذا بخس لها بالتأكيد.

مشكلة الاكتشاف

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

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

لنسمّ هذا مشكلة الاكتشاف: يأتي الوكيل إلى تطبيقك بلا معرفة ما فيه، ويُدفَع ثمن ذلك الجهل في كل مسار يحاول تنفيذه. ففي REST على الوكيل أن يحدس أي نقاط وصول توجد، ويجري استدعاءً، وينظر في الرد ليفهم شكل البيانات، ويلاحظ أنه يحتاج بيانات مرتبطة من مكان آخر، ويجري استدعاءً آخر، ويربط النتائج، ويعالج التقسيم إلى صفحات، ويعيد الكرّة، وهو يحرق طوال ذلك نافذة سياقه على بيانات لا يحتاجها.

وتُسقط GraphQL مشكلة الاكتشاف. فيستطيع الوكيل إجراء استعلام استبطان واحد وتلقّي المخطط كله رداً: كل نوع، وكل حقل، وكل علاقة، وكل مُعامل، وكل وصف. والمخطط ليس ناتجاً منفصلاً قد يتباعد عن الواقع. إنه الواقع نفسه. يولد من الشفرة نفسها التي تحلّ الاستعلامات.

وللوكيل، هذا هو الفرق بين اجتياز مدينة بلا خريطة والبدء بملاحة.

الاستبطان هو التوثيق الذاتي

كل واجهة GraphQL توثّق نفسها. ليس بالمعنى الفضفاض المتمنّي الذي تكون فيه واجهات REST «موثِّقة لنفسها» حين يتذكر أحدهم تحديث مواصفة OpenAPI. واجهات GraphQL توثّق نفسها حرفياً، بالتصميم، كخصيصة جوهرية في البروتوكول.

وهذا يهم للوكلاء بشكل محدد. فقبل إجراء أي طلب بيانات واحد، يستطيع الوكيل أن يسأل الواجهة: ما تستطيع فعله؟ وأي بيانات تملك؟ وكيف يترابط كل ذلك؟ وتجيب الواجهة، كاملاً وصحيحاً وبشكل تافه المعالجة.

تخيّل وكيلاً عليه أن يجد شكاوى الفوترة الأخيرة من العملاء. يستبطن المخطط فيكتشف نوع Customer بحقل tickets، وأن للطلبات تعداد category يتضمن BILLING، وأن للطلبات طابع createdAt وحقل status، وأن بكل طلب اتصال comments. في ثوانٍ يملك خريطة كاملة لنموذج البيانات، ليست من وثائق قد تكون محدّثة أو لا، بل من النظام الحي نفسه.

وهذه هي الخصيصة التي يحاول Model Context Protocol، معيار Anthropic الذي يتيح لمساعدي الذكاء الاصطناعي اكتشاف الأدوات الخارجية واستدعاءها، إضافتها جوهرياً إلى كل نوع من واجهات البرمجة. ومخطط GraphQL هو أصلاً إعلان قدرات بشكل MCP. فالبروتوكول ونموذج البيانات يلتقيان في منتصف الطريق حين يتحدثان اللغة نفسها.

أن تطلب ما تحتاجه بالضبط

واجهات REST تعيد بنى بيانات ثابتة. تستدعي /api/users/123 فتحصل على كل ما قرر الخادم تضمينه في رد المستخدم: الاسم وعنوان البريد وعنوان السكن والتفضيلات وعنوان الصورة وتاريخ إنشاء الحساب وطابع آخر دخول وأربعين حقلاً آخر. وإذا احتجت أيضاً طلبات ذلك المستخدم الأخيرة فذلك استدعاء منفصل. وإذا احتجت بنود تلك الطلبات فذلك استدعاء آخر لكل طلب.

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

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

وتزيل GraphQL هذه المشكلة. فالوكيل يحدد الحقول التي يحتاجها بالضبط:

query {
  user(id: "123") {
    name
    email
    recentOrders(first: 3) {
      status
      total
      items {
        productName
        quantity
      }
    }
  }
}

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

هذا هو النموذج الذي ينبغي أن يستطيع به وكيل ذكي التحدث مع مصدر بيانات. وهو النموذج الذي تشغّله GraphQL بصمت منذ عقد.

طلب واحد بدل اثني عشر

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

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

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

وللوكيل، وهو جوهرياً آلة استدلال تحاول تقليص التعقيد غير الضروري، هذه ميزة كبيرة.

تحويرات بتحقق مدمج

ميزة GraphQL لا تنتهي عند قراءة البيانات. فحين يحتاج الوكلاء إلى فعل شيء (إنشاء سجلات، تغيير حالة، إطلاق مسارات)، تعطي تحويرات GraphQL واجهة منظمة ومتوقعة تتحقق من نفسها.

فحين ينشئ وكيل طلب دعم عبر واجهة REST، عليه تركيب طلب POST بمتن JSON، لكن الشكل الدقيق لذلك المتن (أي الحقول إلزامية، وأيها اختيارية، وأي أنواع متوقعة، وأي قيم صحيحة) معرَّف في وثائق خارجية فقط. وإذا أخطأ، يعرف الوكيل ذلك في زمن التنفيذ، برد خطأ قد يكون مفيداً أو لا.

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

هذا هو الشكل الذي ينبغي أن تستطيع به آلة التحدث مع تطبيق.

المخطط هو العقد

مخطط GraphQL هو عملياً إعلان قدرات مقروء آلياً. يصرّح: هذا كل ما يستطيع هذا التطبيق فعله، وهذه أنواع البيانات المشاركة، وهذا كيف تترابط، وهذه العمليات المتاحة. إنه العقد بين تطبيقك وكل نظام ذكي يريد استخدامه.

وحين يصادف وكيل واجهة GraphQL، لا يحتاج تكاملاً مخصصاً. ولا يحتاج من يكتب موصلاً باليد. يقرأ المخطط ويبدأ العمل. المخطط هو طبقة التكامل.

وهذه هي الخصيصة التي صُمِّم Archie Core حولها. فكل تطبيق يُبنى على Archie Core (واجهة أمامية أو خلفية أو كلتاهما) يحصل على مخطط GraphQL بالمجان. لا كأمر لاحق، ولا كملحق، بل كالواجهة الأساسية. والنتيجة ليست دقيقة الفارق: كل تطبيق يُطلَق على Archie جاهز للوكلاء من اليوم الأول، لأن الوكيل يتحدث تلك اللغة أصلاً.

وفي اقتصاد يختار فيه الوكلاء بشكل متزايد أي أدوات تُستدعى بالنيابة عن مستخدم، فسهولة العمل معك ليست تفصيلاً تقنياً. إنها استراتيجية دخول إلى السوق.

المبادلات الصريحة

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

هذه تحديات هندسية لها حلول معروفة، لا حدود جوهرية. والسؤال هو ما إذا كانت التكلفة تستحق فائدة عصر الوكلاء، والجواب «نعم» بشكل متزايد لكل تطبيق يأخذ هذا المستقبل بجدية.

ابنِ الواجهة التي تستطيع الآلات التفكير بها

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

تعطيك GraphQL مخططاً يصف نفسه ويعمل كإعلان قدرات حي. وجلب بيانات دقيق يحترم حدود سياق الوكيل. وتحويرات مصنَّفة تزيل الحدس. واشتراكات في الزمن الحقيقي تُتيح سلوكاً استباقياً. كل ذلك عبر نقطة وصول واحدة بلغة استعلام واحدة متسقة.

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

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

قراءات ذات صلة

الأساس البنيوي تحت هذا في الواجهة كذبة، وصيغته التجارية في الأساس التجاري لواجهة البرمجة أولاً.

الأسئلة الشائعة

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

ما هي مشكلة الاكتشاف؟ مشكلة الاكتشاف هي التكلفة التي يدفعها وكيل ذكاء اصطناعي حين يأتي إلى تطبيق بلا معرفة أي بيانات وعمليات متاحة. فواجهات REST تجبر الوكيل على الحدس؛ وواجهات GraphQL تجيب باستعلام استبطان واحد يعيد المخطط كله.

كيف تتصل GraphQL بـ Model Context Protocol (MCP)؟ MCP معيار Anthropic الذي يتيح لمساعدي الذكاء الاصطناعي اكتشاف الأدوات الخارجية واستدعاءها. ومخطط GraphQL بشكل MCP أصلاً: يقدّم إعلان القدرات المقروء آلياً الذي يهدف MCP إلى عرضه. فتطبيقات GraphQL تلتقي منظومة الوكلاء في منتصف الطريق.

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

لماذا اختار Archie Core منتج GraphQL كواجهته الأساسية؟ صُمِّم Archie Core بحيث يحصل كل تطبيق يُبنى عليه على مخطط GraphQL بالمجان، وهذا يجعله قابلاً للاكتشاف والاستخدام لوكلاء الذكاء الاصطناعي من اليوم الأول. فالجهوزية للوكلاء خصيصة في البنية لا خصيصة أُضيفت لاحقاً.