إنه عام 2020. أنت الفريق يميل بشكل متزايد نحو بناء تطبيقات ذات صفحة واحدة، أو على الأقل تضمين مكونات غنية ضمن تطبيقات عادية متعددة الصفحات. يبلغ عمر [GraphQL] (https://graphql.org/) [أكثر من عامين] (https://en.wikipedia.org/wiki/GraphQL) الآن، وهو ما يعني أن JavaScript يمكن اعتبار معايير النظام البيئي ناضجة. كنا نشعر بقليل من المغامرة، لذلك تخلينا عن واجهات برمجة تطبيقات JSON المعتادة ودخلنا مباشرةً في هذا المجال - وإليك ما تعلمناه.

تحتاج إلى خادم GraphQL

في معظم الأطر المستخدمة في تطوير الويبفإن أدوات إنشاء واجهة برمجة تطبيقات JSON موجودة بالفعل. يمكنك إنشاء بنية مسار وقبول بعض عمليات التحصيل والبوست بسهولة، ثم إخراج استجابة JSON. حتى أن Ruby on Rails لديه خاصية المشروع تبديل الإعداد الذي يستغني عن أدوات عرض HTML المعتادة ويضع أساسًا متينًا لواجهات برمجة التطبيقات مكانها. ما يلي هو أنه يمكن للمطور الماهر الذي يستخدم أدوات حديثة أن ينشئ واجهة خلفية في دقائق معدودة.

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

هناك نقطة نهاية واحدة فقط

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

يستخدم GraphQL نقطة نهاية واحدة فقط، عادةً ما تكون /جرافكل. سيصل كل طلب إلى واجهة برمجة التطبيقات الخاصة بك كطلب POST في نقطة النهاية تلك، ومن هناك تقع على عاتق خادم GraphQL مسؤولية معرفة ما يريده العميل والاستجابة بشكل مناسب.

للوهلة الأولى يبدو للوهلة الأولى أنه غير عملي: تخيل محاولة القيام بكل شيء في واجهة برمجة تطبيقات JSON بنقطة نهاية واحدة! ومع ذلك، سرعان ما يبدأ الأمر يصبح منطقيًا مع نضوج واجهة برمجة التطبيقات الخاصة بك واستبدال بعض الأشياء بأخرى. عادةً ما يتم الإهمال في واجهات برمجة التطبيقات الكلاسيكية على مستوى مساحة الاسم، والانتقال من v1 إلى v2. يوفر GraphQL مزيدًا من التحكم، حتى إهمال حقل واحد. تخيل أن تكون قادرًا على إخبار مستهلك واجهة برمجة تطبيقات REST بأنك لا تريده أن يستخدم الاسم الحقل واستخدام اسم_وهمي بدلاً من ذلك! اتضح أن ما شعرت أنه غير عملي في البداية هو في الواقع أحد أفضل الميزات.

كل شيء مكتوب

لا تحتوي JSON في الحقيقة على الكثير من الكتابات. هناك السلاسل والأرقام والمصفوفات والكائنات. أبعد من ذلك، أنت غير محظوظ. على النقيض من ذلك في GraphQL، كل شيء يبدأ وينتهي بالأنواع، حتى جذر الاستعلام والطفرة هما مجرد أنواع. تفرض لغة GraphQL DSL التحقق من الأنواع على كل من الخادم والعميل، مما يمنع جميع أنواع المفاجآت السيئة.

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

اقرأ المزيد: اختبار JavaScript...مع روبي؟

المستندات مدمجة

في واجهة برمجة تطبيقات JSON الكلاسيكية، يمكن أن يكون التوثيق فكرة متأخرة. وحتى لو لم تكن كذلك، فهناك الكثير من الطرق للاختيار من بينها. هل نستخدم بعض المخططات مثل OpenAPI? هل نقوم بعد ذلك بتحويلها إلى شكل قابل للقراءة البشرية باستخدام أدوات مثل Swagger؟ أم نقوم فقط بتفريغ مجموعة كاملة من ملفات Markdown في مكان ما؟ على الرغم من أن هذه المشكلة قد تم حلها عدة مرات، إلا أنها لا تزال تتطلب تفكيراً وجهداً واعياً من الفريق - أولاً لبناء المستندات، ثم تحديثها ونشرها. إنها مشكلة أكثر تعقيدًا عندما تحتوي واجهة برمجة التطبيقات على عدة أقسام لا يمكن الوصول إليها إلا من خلال أدوار مستخدمين معينين على سبيل المثال.

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

هناك نوعان فقط من الإجراءات

على عكس GET و POST و POST و PUTCH و PATCH و DELETE في HTTP، هناك نوعان فقط من الإجراءات في GraphQL: الاستعلامات والتعديلات. والفرق الرئيسي هو أن التغييرات يمكن أن تغير حالة النظام وستعمل على تغييرها بينما الاستعلامات ستقرأ البيانات بشكل سلبي فقط.

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

تحتاج إلى عميل إلى حد كبير

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

يقوم كل عميل GraphQL معقول بتنفيذ آلية تخزين النتائج من جانب العميل للتخزين المؤقت، والعديد من الميزات الأخرى. بفضل كل هذه الاختيارات يعد إعداد تهيئة لعميل GraphQL يدويًا على مستوى المبتدئين مهمة مذهلة تمامًا. عند البدء باستخدام GraphQL أوصي بشكل خاص بإلقاء نظرة على أبولو-بوست بما أنها تأتي مع إعدادات افتراضية معقولة للغاية.

يختار العميل البيانات

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

من الصعب التنبؤ بالتعقيد

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

الصفحات المرقمة صعبة للغاية

هذا هو وجع اللسان في الحقيقة. يمكنك أن تشعر بالتأكيد أن GraphQL صُمم في فيسبوك ومن أجله من خلال النظر إلى الطريقة التي تعمل بها آلية ترقيم الصفحات المقصودة. إن ما يسمى بالاتصالات هي في الأساس تدفقات لا نهاية لها من حواف الرسم البياني، ويتم التنقل فيها من خلال المؤشرات بدلاً من الصفحات الأكثر تقليدية. في حين أنه من السهل أن ترى كيف يتناسب ذلك مع موجز لا نهائي للمنشورات على غرار فيسبوك، إذا كنت تريد قائمة مرتبة بشكل منظم مع إمكانية الانتقال إلى الصفحة 42، على سبيل المثال، ستواجه وقتًا أصعب بكثير. هناك بالطبع طرق للتغلب على ذلك، ولكن هذا ما هي عليه - حلول بديلة.

هل سنفعلها مرة أخرى؟

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

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

اقرأ أيضًا:

– كيفية إدارة المطورين عن بُعد بفعالية؟ دليل CTOs CTO

– Python مقابل روبي؟ ما التقنية التي يجب أن تستخدمها لتطوير المنتج؟

– دليل سريع لبناء وتطوير السوق الخاص بك. ما الذي يستحق أن تعرفه؟