Smashing Podcast الحلقة 31 مع Eve Porcello: ما هي GraphQL؟

في هذه الحلقة ، نتحدث عن GraphQL. ما هو ، وكيف يحل بعض مشاكل API الشائعة؟ لقد تحدثت مع الخبيرة إيف بورسيلو لمعرفة ذلك.

وتظهر الملاحظات

• حواء على تويتر
• طريق القمر السريع لشركة Eve
• تعلم GraphQL من O'Reilly
• اكتشف مسارك عبر GraphQL Wilderness - انطلاق ورشة عمل GraphQL الخاصة بحواء في أوائل عام 2021

تحديث اسبوعي

• كيفية استخدام MDX المخزنة بشكل سليم في موقع ويب Next.js
  كتبه جيسون لينجستورف
• بناء Chatbot محادثة تم تمكينه في البرمجة اللغوية العصبية باستخدام Dialogflow من Google
  كتبه نواني فيكتوري
• الاعتبارات الأخلاقية في أبحاث UX: الحاجة إلى التدريب والمراجعة
  كتبه فيكتور يوكو
• جعل مواقع الويب أسهل في التحدث إليها
  بقلم فريدريك أوبراين
• كيف تصمم واجهة مستخدم بسيطة عندما يكون لديك حل معقد
  بقلم سوزان سكاكا

نسخة طبق الأصل

درو ماكليلان: هي مهندسة برمجيات ، ومعلمة ، ومؤلفة ، ومؤسس مشارك لشركة تطوير المناهج والتدريب ، Moon Highway. بدأت حياتها المهنية في كتابة المواصفات الفنية وإنشاء تصميمات تجربة المستخدم لمشاريع الويب. منذ أن بدأت Moon Highway في عام 2012 ، أنشأت محتوى فيديو لموقع egghead.io و LinkedIn Learning ، وشاركت في تأليف الكتابين Learning React و Learning GraphQL for O'Reilly's Media.

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

درو: مرحبًا حواء ، كيف حالك؟

إيف بورسيلو: أنا محطمة.

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

درو: إذن ، هيئ المسرح لنا ، إذا صح التعبير ، إذا كنت مطورًا للواجهة الأمامية ، فأين توجد فتحة GraphQL في النظام البيئي وما هي الوظيفة التي تؤديها بالنسبة لي؟

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

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

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

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

حواء: نعم ، هذا صحيح تمامًا. بالضبط.

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

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

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

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

حواء: نعم بالضبط. لذلك يصبح استعلامك بعد ذلك كيف تسأل ، وكيف تقوم بالتصفية ، وكيف تستوعب أي نوع من المعلومات من أي مكان.

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

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

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

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

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

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

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

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

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

درو: مع GraphQL ، لديك نقطة نهاية واحدة فقط تطلق استفساراتك عليها وستحصل على الرد المناسب.

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

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

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

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

درو: لذلك يمكنك المزج والمطابقة في استعلام. يمكنك تقديم طلب يعيد الكثير من أنواع البيانات المختلفة في طلب واحد. هل هذا صحيح؟

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

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

حواء: أجل. هذا هو الهدف بالكامل ، وهو مجرد استعلام واحد ، حدد كل حقل تريده ، ثم أعيده في إجابة واحدة.

درو: والاستعلامات مبنية على JSON ، هل هذا صحيح؟

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

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

حواء: بالتأكيد. هذا هو الشيء الحقيقي المثير والقوي في GraphQL وهو أنه يمكنك نقل الكثير من هذا المنطق إلى الخادم. إذا كان لديك استعلام معقد ، نوع معين من المستخدمين تريد الحصول عليه ، فكل ما عليك فعله في المخطط هو قول "احصل على مستخدم معقد" ، ثم على الخادم ، ستكون هناك وظيفة حيث يمكنك كتابة كل المنطق بأي لغة تريدها. تعد JavaScript نوعًا من أكثر لغات تطبيق GraphQL شيوعًا ، ولكن لا يتعين عليك استخدامها على الإطلاق. إذن ، Python ، Go ، C ++ ، كل ما تريد استخدامه ، يمكنك إنشاء خادم GraphQL باستخدام ذلك. لكن نعم ، يمكنك تحديد استعلام معقد كما تريد.

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

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

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

حواء: بالضبط.

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

حواء: نعم ، صحيح تمامًا.

درو: إذن ، هل خادم GraphQL مسؤول عن تنسيق الاستجابة ، أم أنك تحتاج إلى القيام بذلك في منطق جانب الخادم؟

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

درو: يقول العميل ، "أريد مستخدمًا معقدًا" ، يتلقى الخادم ذلك في استعلام ويمكن أن يقول ، "حسنًا ، سأبحث عن محلل المستخدم المعقد." هل هذا صحيح؟

حواء: مم-هم (بالإيجاب).

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

حواء: نعم بالضبط.

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

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

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

حواء: نعم بالضبط.

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

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

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

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

حواء: نعم ، إنه خادم حقيقي. لذا فإن أكثر تطبيقات GraphQL شيوعًا هي خوادم Node.js. عندما تم إصدار GraphQL كمواصفات ، أصدر الفريق هذا التطبيق المرجعي في JavaScript ، وهو نوع من خادم Node كان بمثابة إرشادات لجميع هؤلاء الذين ظهروا. لكن نعم ، يمكنك تشغيل هذه الخوادم في مثيلاتها الخاصة. يمكنك وضعها على Lambda. إذن هناك Apollo Server Express ، و Apollo Server Lambda ؛ كل أنواع التطبيقات المختلفة التي يمكنك استخدامها لتشغيل هذا الشيء فعليًا.

درو: لقد ذكرت بإيجاز قبل مفهوم المخطط الذي يمتلكه الخادم.

حواء: أجل.

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

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

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

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

درو: هل هناك أي تقاطع بين ذلك و TypeScript؟ هل هناك نوع من التآزر بين الاثنين؟

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

حواء: ... لكي تكون نوعًا من القاعدة الفعلية في JavaScript ، فإنها تتوافق جيدًا معًا.

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

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

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

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

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

حواء: حسنًا ، أعتقد أن GraphQL في الغالب ليست 100٪ من الحلول ، ولكن يتم إرسال كل استعلام GraphQL تقريبًا عبر HTTP. لذلك إذا كنت ترغب في تعقب مكان حدوث هذه الطلبات المتعددة ، فمن المحتمل أن تكون مشكلة مألوفة إلى حد ما للأشخاص الذين يستخدمون بيانات الراحة لتطبيقاتهم. إذن ، هناك بعض الأدوات مثل Paulo Client Dev Tools و Urkel Dev Tools لمطوري الواجهة الأمامية الذين يشبهون ، "ما الذي يحدث؟ ما هي الاستفسارات الموجودة في هذه الصفحة؟ " يمنحك ذلك رؤى واضحة حقًا لما يحدث. هناك نوع من عدة مدارس فكرية مع ذلك. هل نقوم بإنشاء استعلام واحد ضخم وضخم لجميع البيانات الخاصة بالصفحة؟ أو هل نقوم بإنشاء استعلامات أصغر لتحميل البيانات لأجزاء مختلفة من التطبيق؟ كلاهما كما قد تتخيل ، لهما عيوبه الخاصة ، فقط لأنه إذا كان لديك استعلام كبير ، فأنت تنتظر المزيد من الحقول.

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

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

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

درو: وهل هذا أمر بسيط مثل الاستعلام عن البيانات؟ استدعاء الطفرة بنفس السهولة؟

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

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

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

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

حواء: أعتقد أن المكان الذي قد تواجه فيه GraphQL صعوبة في إنشاء خريطة فردية لـ-

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

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

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

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

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

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

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

حواء: كامنة في الأدغال ، دائما مع التكنولوجيا ، أليس كذلك؟ أعتقد أن أحد الأشياء غير المضمنة في GraphQL ، ولكن يمكن تنفيذها دون الكثير من المتاعب هو أمان واجهة برمجة التطبيقات. على سبيل المثال ، ذكرت أنه إذا كان لدي استعلام ضخم ، فقد تحدثنا عن هذا بتفويض ، ولكن من المخيف أيضًا فتح واجهة برمجة تطبيقات حيث يمكن لشخص ما إرسال استعلام ضخم متداخل ، أو أصدقاء الأصدقاء ، أو أصدقاء الأصدقاء ، أو أصدقاء الأصدقاء ، أسفل وأسفل السلسلة. وبعد ذلك ، فأنت تسمح للناس بشكل أساسي بـ DDoS من خلال هذه الاستفسارات الضخمة. So there's things that you can set up on the server to limit query depth and query complexity. You can put queries on a safe list. So maybe your front ends, you know what they all are and it's not a public API. So you only want to let certain queries come over the wire to you. So I would say before rolling that out, that is definitely a possible gotcha with the GraphQL.

Drew: You do a lot of instruction and training around GraphQL, and you've co-written the O'Reilly 'animal' book with Alex Banks called Learning GraphQL. But you've got something new that you're launching early in 2021, is that right?

Eve: That's right. So I have been collaborating with egghead.io to create a full stack GraphQL video course. We're going to build an API and front end for a summer camp, so everything is summer camp themed. And yeah, we're just going to get into how to work with Apollo server, Apollo client. We will talk about scaling GraphQL APIs with Apollo Federation. We'll talk about authorization strategies and all sorts of different things. So it's just kind of collecting the things that I've learned from teaching over the past, I don't know, three or four years GraphQL and putting it into one spot.

Drew: So it's a video course that… Is it all just self-directed, you can just work your way through at your own pace?

Eve: Yeah, exactly. So it's a big hefty course so you can work through it at your own pace. إطلاقا.

Drew: Oh, that sounds really good. And it's graphqlworkshop.com, is that right?

Eve: Graphqlworkshop.com, exactly.

Drew: And I'm looking forward to seeing that released because I think that's something that I might need. So I've been learning all about GraphQL. What have you been learning about lately?

Eve: I've also been looking into Rust lately. So I've been building a lot of Rust Hello Worlds, and figuring out what that is. I don't know if I know what that is yet, but I have been having fun tinkering around with it.

Drew: If you dear listener, would like to hear more from Eve, you can find her on Twitter where she's @eveporcello, and you can find out about her work at moonhighway.com. Her GraphQL workshop, discover your path through the GraphQL wilderness, is coming out early in 2021 and can be found at graphqlworkshop.com. Thanks for joining us today, Eve. هل عندك كلمات فراق؟

Eve: Parting words, have fun with GraphQL, take the plunge, you'll enjoy it, and thanks so much for having me. أنا أقدر ذلك.