GraphQL: هل هو “قاتل” واجهة برمجة تطبيقات REST API؟

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

في هذه المقالة سأغطي هذه الأسئلة، ولكن الإجابة المختصرة هي: لا، لا داعي للقلق لأن GraphQL لن “يقتل” واجهة برمجة تطبيقات REST، ولا داعي للقلق أيضًا بشأن إعادة كتابة أساليب REST API التي تعمل بالفعل.

إذن، ما هي الصفقة مع GraphQL إذن؟

أحد المفاهيم الخاطئة لدى معظم الأشخاص الذين يصلون إليّ هو أن GraphQL ليس هنا ليحل محل الواجهة الخلفية بأكملها.

لن تحل GraphQL محل الواجهة الخلفية. ولا الواجهة الأمامية.

GraphQL عبارة عن لغة استعلام، وطريقة لتحديد المعلومات التي تبحث عنها لواجهة برمجة التطبيقات الخاصة بك، ووقت تشغيل سيحصل على تلك المعلومات من بياناتك الموجودة مسبقًا.

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

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

لذلك إذا كنت تستخدم Parse 3.0 أو أكثر، فلا داعي للقلق على الإطلاق. ما عليك سوى اختيار إصدار أكثر من 3.5.0 وأنت على ما يرام.
أما إذا كنت تستخدم Parse 2.X، فسيكون عليك القيام ببعض أعمال إعادة الترميز.

ولماذا GraphQL إذا كانت واجهة برمجة تطبيقات REST تعمل بالفعل؟

يظهر هذا السؤال أيضًا كثيرًا، وأعتقد حقًا أن هناك بعض المزايا الرئيسية لاختيار GraphQL على REST API.

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

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

هل قلت قيمة؟

نعم قلت ذلك.

يحتوي GraphQL على بعض المزايا الرئيسية التي من شأنها تبسيط تطوير التعليمات البرمجية والصيانة بمرور الوقت ويمكن أن تساعدك حتى في توفير تكاليف نقل البيانات! نعم! لقد قرأت ذلك بشكل صحيح.

دعنا نتناول كل عنصر على حدة:

• تبسيط تطوير التعليمات البرمجية

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

• تبسيط الصيانة

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

• وفِّر في نقل البيانات

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

جرّب الأمر

إن أفضل طريقة لمعرفة الفوائد التي يمكن أن تجلبها GraphQL إلى عملية التطوير الخاصة بك هي تجربتها.
إليك بعض السيناريوهات التي يمكنك اللعب بها ومعرفة كيف تتصرف:

• حاول إنشاء استعلام GraphQL دون تحديد ما تريد استرجاعه بالضبط

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

فقدان ما أقوم باسترجاعه

ها أنت ذا!

• حاول تغيير كائن باستخدام استعلام

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

استعلام لتغيير البيانات؟ لا لا لا لا!

لقد غطتك الطفرات!

• كائنات متعددة، استعلامات متعددة؟ لا! استعلام واحد!

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

الإصدار؟ لماذا؟

شيفرة الإصدار هي من موضة 2018.
أضف حقولاً جديدة إلى استعلامك. ستظل المكالمات القديمة تعمل:

هذا يعمل

هذا يعمل أيضًا. ستظل المكالمات إلى النوع القديم تعمل.

الحقول المهملة التي قلتها؟ سهل جدًا أيضًا:

الخلاصة

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

ستبقيك على المسار الصحيح عندما تنزلق. سيخبرك بما يمكنك فعله وما لا يمكنك فعله.

جنبًا إلى جنب مع Parse والطرق التي يتم إنشاؤها تلقائيًا (العامة والخاصة) والوثائق، ستجعلك تتعلم طريقها بسهولة.

إذا لم تجربها من قبل، فعليك أن تجربها. كل الأطفال الرائعين يفعلون ذلك.

إذا كنت ترغب في معرفة المزيد عن GraphQL مقابل REST، راجع منشورنا على موقع Medium.