GraphQL
نمط واجهة يطلب فيه السائل ما يحتاجه بالضبط لا أكثر. مفيد هنا لأنه يجعل تضييق النطاق أسهل لا أصعب.
نمط واجهة يطلب فيه السائل ما يحتاجه بالضبط لا أكثر. مفيد هنا لأنه يجعل تضييق النطاق أسهل لا أصعب.
ماذا تعرض واجهة GraphQL، ولماذا يهمّ ذلك هنا
ما يميّز هذا النمط أن الطلب يحدّد الحقول المطلوبة بدقة. وهذه خاصية تقنية لها أثر مباشر على الحوكمة: القراءة تكون بالضبط ما هو مطلوب لا أكثر.
وهذا يبسّط المراجعة الأمنية، لأن سؤال «ما الذي يُقرأ» تكون إجابته صريحة بحكم بنية الطلب نفسه لا بحكم اتفاق منفصل.
وفي المقابل، المرونة نفسها تعني أن النطاق يجب أن يُقيَّد صراحة، وإلا صار الاتصال قادراً على قراءة أكثر مما يحتاج.
- الحقول المحددة — الطلب يحدّدها بدقة بحكم بنيته.
- النطاق المقيَّد — ما يُسمح بطلبه يُحدَّد صراحة.
- القراءة فقط — بلا عمليات تغيّر شيئاً.
- بيانات اعتماد خدمة — منفصلة وقابلة للإيقاف.
- الحدود — قيود العمق والتعقيد كما تعرّفونها.
أسئلة يجيب عنها Elbi عبر GraphQL
ما حالة هذا؟
قراءة الحقول المحددة بترجمة مفهومة.
ما القيمة الحالية؟
الحقل المطلوب بالضبط لا أكثر.
هل هذا موجود؟
بحث ضمن النطاق المسموح.
متى تغيّر هذا؟
الطابع الزمني المسجّل.
ما المرتبط بهذا؟
العلاقات المسموح بقراءتها فقط.
من المسؤول؟
الحقل المسجّل في المخطط، حيث يكون عرضه مناسباً.
كيف يعمل Elbi مع واجهة GraphQL
- نقطة نهاية واحدة وأسئلة كثيرةتخدم واجهة GraphQL عادة كل شيء عبر نقطة نهاية واحدة، ونص الاستعلام هو الذي يحدد ما يعود. ولذلك لا يمكن ضبط النطاق بالسماح بمسار كما في REST، بل بتحديد الاستعلامات المسموح بها.
- استعلامات مسمّاة تُكتب مسبقاًكل سؤال يجيب عنه Elbi يقابله استعلام مسمّى يُكتب ويُراجع أثناء التشغيل، مثل جلب حالة طلب وموعد توصيله برقمه المرجعي. وحيث يدعم الخادم الاستعلامات المحفوظة مسبقاً أو قائمة عمليات مسموحة، تُسجَّل هذه الاستعلامات هناك أيضاً، فلا يُقبل من بيانات الاعتماد غيرها.
- متغيرات لا تركيب نصوصالتفاصيل التي تُجمع من المحادثة، كالرقم المرجعي أو التاريخ، تُمرَّر متغيراتٍ محددة الأنواع. وأنواع المخطط ترفض أي قيمة بشكل خاطئ قبل أن يُنفَّذ الاستعلام.
- الحقول التي تحتاجها الجملة فقطلأن الطالب هو من يختار الحقول، يستطيع الاستعلام أن يطلب الحالة والتاريخ ولا شيء غيرهما. فتبقى الاستجابات صغيرة، وتبقى البيانات الشخصية التي لا تحتاجها الإجابة داخل نظامكم.
- الخطأ قد يصل برمز نجاحكثيراً ما تعيد خوادم GraphQL الرمز 200 ومعه مصفوفة أخطاء، وأحياناً بيانات جزئية. والاستجابة التي تحمل أخطاء تُعامل على أنها استعلام فاشل، ويُقال ذلك صراحة، ولا تُبنى إجابة من نصف نتيجة.
- عمليات التغيير مستثناة إلا بالاسمالتغيير في GraphQL يتم عبر ما يسمى mutations، وهي لا تُرسل افتراضياً. وإن احتجتم واحدة، تُسمّى وحدها بمعاملات ثابتة، ويمكن أن تنتظر تأكيد شخص، ولا يُرسل غيرها من عمليات المخطط أبداً.
استعلامات GraphQL وصلاحيات المخطط، وما يبقى بأيديكم
الاستعلامات المسمّاة وحدها هي ما يُرسل. أما الاشتراكات (subscriptions) واستكشاف المخطط (introspection) فلا حاجة إليهما للإجابة عن الأسئلة، وتبقيان خارج الاستخدام.
وخادم GraphQL يفرض التفويض عادة على مستوى كل نوع وكل حقل. فصلاحيات بيانات الاعتماد هي السقف، وتمرير هوية السائل يتيح للخادم أن يضيّق النتائج إلى سجلاته وحده.
وبيانات الاعتماد في الغالب رمز وصول أو عميل OAuth يُصدر في نظامكم، بأضيق نطاق تسمح به الواجهة. وإلغاؤه يقطع الاتصال فوراً دون الرجوع إلينا.
والاستعلامات لا تطلب إلا الحقول التي تحتاجها الإجابة، والاستجابات تخدم تلك الإجابة ولا تُحفظ. ومحتوى رسائل المحادثة يُتلف خلال 24 ساعة، ولا يُعرض على أي خدمة ذكاء اصطناعي خارجية.
ويُسجَّل كل استدعاء باسم العملية ومتغيراتها ونتيجتها والمحادثة، فيرى المراجع أي استعلام مسمّى نُفّذ ولأي رقم مرجعي، لا طلباً مجهولاً إلى نقطة النهاية. وانتهاء المهلة وأخطاء الخادم ورفض الاستعلام لكلفته تُبلَّغ جميعها تعذّراً، مع عرض التحويل إلى موظف.
ما الذي يحلّ محلّه هذا
ما يحلّ محلّه هذا هو القراءة الزائدة. في الأنماط الأخرى، الاستجابة تأتي كاملة ثم يُنتقى منها، وهذا يعني أن بيانات لم تكن مطلوبة قد عبرت الشبكة ووصلت إلى مكان لم تكن بحاجة للوصول إليه.
وهذه مسألة تُطرح في المراجعات: لماذا قُرئ ما لم يُستخدم. والإجابة «هكذا تعمل الواجهة» ليست إجابة مريحة.
وهذا النمط يزيل السؤال من أصله لأن ما يُطلب هو ما يُقرأ، لا أكثر.
أين يناسب الربط عبر GraphQL
البرمجيات الحديثة
أشهر بيئة لهذا النمط.
الخدمات الرقمية
واجهات مرنة بحقول محددة.
التقنية
تضييق النطاق بحكم البنية.
الامتثال
سؤال «ما الذي يُقرأ» له إجابة صريحة.
العمليات
بيانات تشغيلية بحقول دقيقة.
الإدارة
أرقام محددة دون قراءة زائدة.
كيف تستفيدون من واجهة GraphQL
يثبت GraphQL جدواه حين تمتد الإجابة عبر سجلات مترابطة. سؤال «متى يصل طلبي؟» قد يحتاج الطلب وشحنته وآخر حدث لدى شركة الشحن؛ وفي GraphQL يمكن أن يكون ذلك استعلاماً واحداً يعيد ثلاثة حقول، حيث قد تحتاج REST إلى ثلاثة استدعاءات.
ابدأوا بالأسئلة التي تقع بياناتها متقاربة في المخطط، واكتبوا استعلاماتها على بيئة اختبار. وأبقوا كل استعلام قليل العمق؛ فالاستعلام الذي يتنقل من العميل إلى طلباته إلى مدفوعاته إلى بطاقاته هو بالضبط التنقّل الذي لم يقصد أحد الموافقة عليه.
وإن كانت الواجهة تُظهر كلفة الاستعلام أو تعقيده، فافحصوا كل استعلام مسمّى بها قبل الإطلاق. الاستعلام الرخيص لعميل والمكلف لآخر ذي سجل طويل أفضل أن يُكتشف في الاختبار لا في رفض صباح يوم مزدحم.
ما الذي يتطلبه ربط واجهة GraphQL
- الأسئلة لا المخططالمخطط يُظهر كل ما يمكن أن يُسأل، والتواصل الفعلي يُظهر ما يُسأل فعلاً. والاختيار يكون من القائمة الثانية.
- كتابة الاستعلامات ومراجعتهاكل استعلام مسمّى، بمتغيراته وحقوله المختارة، يُكتب ويراجعه فريقكم. ومجموع هذه الوثائق هو النطاق، وهو ما سيقرؤه المدقّق.
- تسجيلها حيث يسمح الخادمإن كان خادم GraphQL لديكم يدعم الاستعلامات المحفوظة مسبقاً أو قائمة عمليات مسموحة، تُسجَّل الاستعلامات المراجَعة هناك، فلا تستطيع بيانات الاعتماد تنفيذ غيرها.
- إصدار بيانات اعتماد ضيقةيصدر فريقكم الرمز أو عميل OAuth بأقل وصول تحتاجه الاستعلامات، ويحتفظ بالقدرة على تغييره أو إلغائه.
- اختبار العمق والكلفة والأخطاءأرقام مرجعية غير موجودة، وعميل بسجل طويل جداً، وحقل لا تملك بيانات الاعتماد قراءته، وأخطاء جزئية، وخادم يرفض استعلاماً لارتفاع كلفته. وكل حالة يجب أن تعطي إجابة متوقعة.
- الإطلاق باستعلامات قليلة ثم الإضافةابدأوا بأكثر الأسئلة تكراراً، وراجعوا شهراً من الحركة الحقيقية، ثم أضيفوا استعلامات أخرى.
البيانات الشخصية والتنقّل في المخطط
في المخطط البياني، نادراً ما تبعد البيانات الشخصية أكثر من خطوة أو خطوتين: عقدة العميل ترتبط بالعناوين والطلبات والمدفوعات ووثائق الهوية. وبموجب نظام حماية البيانات الشخصية فالسؤال هو ما يُعالَج فعلاً، وفي GraphQL يحدده ما يختاره كل استعلام من حقول. ومراجعة هذه الاختيارات هي مراجعة الخصوصية نفسها.
اختاروا ما تحتاجه كل إجابة فقط، وفضّلوا المعرّفات على الكائنات الكاملة، وأبقوا الأنواع الحساسة خارج كل استعلام ما لم يحتجها تدفق بعينه. وما يسترجعه Elbi يُستخدم للإجابة، والمحادثة التي تحملها تُتلف خلال 24 ساعة.
وبذلك تصبح أسئلة المراجعة الأربعة قصيرة الإجابة: ما يُقرأ: حقول الاستعلامات المسمّاة. ومن يراه: السائل ضمن صلاحياته. وأين يذهب: لا يتجاوز الإجابة. وكم يبقى: لا يتجاوز 24 ساعة، وغالباً ينتهي بانتهاء المحادثة.
GraphQL وREST، ومتى يكون كلٌّ منهما المدخل الصحيح
حين لا يوفّر النظام إلا GraphQL، كما تفعل اليوم بعض منصات التجارة وخدمات SaaS لواجهتها الرئيسية، فهو المدخل. وحين يوفّر الاثنين، تكون REST عادة أبسط في ضبط النطاق لأن كل عملية مسموحة مسار مستقل؛ ويكون GraphQL الخيار الأنسب حين تحتاج الإجابة حقولاً من سجلات مترابطة عدة، أو حين تعيد REST أكثر بكثير مما يلزم.
وبعض الفرق تترك للمساعد الذكي أن يركّب استعلامات GraphQL بنفسه من المخطط. وهذا مرن، لكنه أيضاً مصدر مشكلات التنقّل والكلفة، لأن أحداً لا يراجع الاستعلام قبل تنفيذه. والاستعلامات المسمّاة المراجَعة لا تخسر من كفاءة GraphQL إلا القليل، وتُبقي الاتصال قابلاً للشرح.
والخطأ الشائع الآخر هو اعتبار رمز النجاح في HTTP نجاحاً. ففي GraphQL تُبلَّغ الإخفاقات في مصفوفة الأخطاء.
ما الذي تراه المؤسسات عادة
أسئلة متكررة
لا. العمليات التي تغيّر شيئاً مستثناة، والافتراضي قراءة فقط.
لا. النطاق يُقيَّد صراحة. المرونة ميزة تقنية لكنها تحتاج تقييداً واعياً.
تُحترم كما تعرّفونها. والاستعلامات العميقة غير المقيَّدة مشكلة أداء معروفة في هذا النمط.
كبيانات اعتماد خدمة منفصلة قابلة للإيقاف.
لا. تُترجم إلى جملة مفهومة.
بإيقاف بيانات اعتماد الخدمة.
اربط Elbi بواجهة GraphQL لديكم
استعلامات مسمّاة ومراجَعة على مخططكم أنتم، تُجاب بالعربية والإنجليزية.