GraphQL حين تخدم واجهة واحدة عملاء مختلفين جدًا

ما هي GraphQL؟

في واجهة REST، يقرر الخادم ما تعيده كل نقطة. فتطبيق جوال يحتاج ثلاثة حقول من كائن فيه أربعون ينزّل الأربعين، وشاشة تحتاج بيانات من ثلاثة كائنات تقوم بثلاث رحلات. وعلى اتصال سريع لا يلاحظ أحد؛ وعلى 4G في مصعد، المشكلتان هما سبب شعور التطبيق بالبطء.

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

والمخطط مكتوب بأنواع وقابل للاستكشاف، ما يعني أن الأدوات تستطيع توليد كود العميل والتوثيق من الخادم تلقائيًا — الفائدة نفسها التي يقدمها FastAPI، مطبقة على رسم بياني من البيانات لا على قائمة نقاط.

متى نختار GraphQL

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

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

متى لا نستخدم GraphQL

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

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

ما الذي نبنيه بـ GraphQL

واجهة واحدة للويب والجوال والشركاء

حيث يحتاج ثلاثة عملاء بيانات متداخلة لكن مختلفة. فيطلب كل منهم شكله من مخطط واحد، فلا تتطلب إضافة حقل لفريق الجوال نقطة جديدة ولا تخاطر بكسر تطبيق الويب.

طبقة فوق عدة أنظمة قائمة

حيث تعيش البيانات في نظام ERP وCRM وقاعدة بيانات، يستطيع GraphQL تقديمها كرسم واحد فتطرح الواجهة سؤالًا واحدًا بدل تنسيق ثلاثة استدعاءات ودمج النتائج بنفسها.

واجهات برمجية يستهلكها عملاء عدة

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

تطبيقات جوال على اتصالات ضعيفة

طلب واحد يعيد بالضبط الحقول التي تعرضها الشاشة، بدل أربعة استدعاءات REST يحمل كل منها بيانات ترميها الشاشة. وعلى اتصال 3G في موقف سيارات تحت الأرض، ذلك الفارق مرئي.

كيف نطلق مشاريع GraphQL

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

ومع تحميل مُجمَّع للسجلات المرتبطة، وإلا صار استعلام بسيط مئات الرحلات إلى قاعدة البيانات — وهي أشيع طريقة تنتهي بها واجهة GraphQL أبطأ من REST التي حلّت محلها.

ما تكلّفك GraphQL

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

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

التخزين المؤقت أصعب فعلًا منه مع REST. فلنقطة REST عنوان تستطيع شبكة توصيل تخزينه؛ واستعلام GraphQL جسم POST لن تمسّه معظم طبقات التخزين دون عمل إضافي.

وتحديد المعدل أقل بداهةً أيضًا — فطلب واحد قد يطلب قدرًا هائلًا من البيانات، فالتحديد بعدد الطلبات لا يحمي شيئًا. وتحليل كلفة الاستعلام هو الجواب، ويحتاج بناءً لا تفعيلًا.

أسئلة تُطرح علينا عن GraphQL