جولة قصيرة في GraphQL

مرحبا يا هبر!


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

يعمل مؤلف مقالة اليوم ، Robin Viruch ، أيضًا على كتاب عن GraphQL والمكتبات لهذه اللغة ، وفي مقال اليوم يشرح بإيجاز مزايا وخصائص GraphQL كبديل لـ REST



عندما يتعلق الأمر بطلبات الشبكة بين تطبيقات العميل والخادم ، يتم اختيار REST في الغالب كجسر بين عالمي العميل والخادم. في REST ، يتطور كل شيء حول فكرة "نحتاج إلى موارد يمكن الوصول إليها عن طريق عنوان URL". يمكنك قراءة مورد باستخدام طلب HTTP GET ، وإنشاء مورد باستخدام طلب HTTP POST ، وتحديثه وحذفه باستخدام طلبات HTTP PUT و DELETE . تسمى هذه العمليات CRUD (إنشاء ، قراءة ، تحديث ، حذف). يمكن أن يكون المصدر أي محتوى يتم تلقيه من المؤلفين أو المستخدمين أو مأخوذ من المقالات. عند استخدام REST ، لا يكون تنسيق نقل البيانات مشفرًا ، ولكن غالبًا ما يتم استخدام JSON لهذا الغرض. في النهاية ، يمكّن REST الاتصال بين التطبيقات عبر بروتوكول HTTP العادي باستخدام عناوين URL وطرق HTTP.

 //    REST GET https://api.domain.com/authors/7 //   JSON { "id": "7", "name": "Robin Wieruch", "avatarUrl": "https://domain.com/authors/7", "firstName": "Robin", "lastName": "Wieruch" } 

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

ما هو GraphQL؟

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

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

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

 //  GraphQL author(id: "7") { id name avatarUrl articles(limit: 2) { name urlSlug } } //   GraphQL { "data": { "author": { "id": "7", "name": "Robin Wieruch", "avatarUrl": "https://domain.com/authors/7", "articles": [ { "name": "The Road to learn React", "urlSlug": "the-road-to-learn-react" }, { "name": "React Testing Tutorial", "urlSlug": "react-testing-tutorial" } ] } } } 

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

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

فوائد GraphQL

فيما يلي الفوائد الرئيسية لاستخدام GraphQL في تطبيق.

أخذ عينات البيانات التعريفية

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

لا إعادة أخذ عينات عند العمل مع GraphQL

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

GraphQL للتفاعل ، الزاوية ، العقدة ، إلخ.

GraphQL هو حل واعد ليس فقط لمطوري React. فليكن Facebook هو الذي تفوق على GraphQL ، وعلى جانب العميل ، يستخدم Facebook React ، في الواقع ، هذه اللغة ليست مرتبطة بأي حل للواجهة الأمامية أو الخلفية. تمت كتابة التنفيذ المرجعي لـ GraphQL بلغة JavaScript ، لذلك يمكن دمج GraphQL مع مكتبات Angular و Vue و Express و Hapi و Koa وغيرها من مكتبات JavaScript في أجزاء العميل والخادم. علاوة على ذلك ، لا ينطبق هذا فقط على نظام جافا سكريبت. يقلد GraphQL REST في جانب واحد ، والذي أصبح شائعًا بسببه: واجهة GraphQL مستقلة عن لغة البرمجة (لغة الاستعلام) المستخدمة في توصيل كائنين (على سبيل المثال ، العميل والخادم). لذلك ، يمكن استنساخ مواصفاته بأي لغة برمجة.

من يستخدم GraphQL؟

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

• جيثب [1] [2]
• Shopify [1] [2]
• تويتر
• كورسيرا
• صرخة
• وورد
• اوقات نيويورك
• Samsara
• وآخرون ...

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

المصدر الوحيد للحقيقة

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

يتبع GraphQL الاتجاهات الحالية

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

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

كيف غرز مخطط GraphQL

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

الاستبطان GraphQL

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

مكتوب بقوة GraphQL

GraphQL هي لغة استعلام مكتوبة للغاية مكتوبة بلغة تعريف المخطط التعبيرية (SDL) لـ GraphQL. تتمتع هذه اللغة بنفس المزايا التي تتمتع بها أي لغة برمجة مكتوبة بقوة. وهي أقل عرضة للخطأ ويمكن التحقق من صحتها في وقت الترجمة ويمكن الاعتماد عليها للتكامل مع ميزات IDE / Editor المدعومة مثل الإكمال التلقائي ودعم الإدخال.

إصدار GraphQL

ليس لدى GraphQL إصدارات API التي اعتدنا عليها في REST. من الطبيعي في REST تقديم عدة إصدارات من نفس واجهة برمجة التطبيقات (مثل api.domain.com/v1/ ، api.domain.com/v2/) ، نظرًا لأن الموارد أو بنيتها يمكن أن تتغير بمرور الوقت. في GraphQL ، يمكنك ترجمة واجهات برمجة التطبيقات إلى واجهات برمجة تطبيقات غير مستحسن على المستوى الميداني. لذلك ، يتلقى العميل تحذيرًا عندما يصل إلى حقل غير مستحسن. بعد مرور بعض الوقت ، يمكن استبعاد الحقل غير الموصى به من النظام ، ثم لن يستخدمه المزيد من العملاء. وبالتالي ، يمكن تطوير واجهة برمجة التطبيقات GraphQL API دون الحاجة إلى الإصدار.

تزايد النظام البيئي GraphQL

النظام البيئي GraphQL ينمو. لا يتعلق الأمر فقط بالتكامل مع المحررين و IDEs المتعلقة بالطبيعة المكتوبة بقوة GraphQL ؛ لـ GraphQL على هذا النحو ، هناك تطبيقات جديدة كاملة. على سبيل المثال ، يمكنك استدعاء Postman ، الذي تم استخدامه عند العمل مع REST API ، والآن لنفس الغرض ، ولكن مع API GraphQL أو GraphiQL أو GraphQL Playground يتم استخدامه. هناك أيضًا مكتبات مختلفة لك ، على سبيل المثال ، Gatsby.js ، وهو مولد مواقع ويب ثابت لـ React يستخدم GraphQL. على سبيل المثال ، يتيح لك Gatsby.js كتابة محرك مدونة يملأ مدونتك بالمحتوى أثناء الإنشاء من خلال واجهة برمجة تطبيقات GraphQL. لذلك ، سيكون لديك أيضًا CMSs بدون جزء العميل (مثل GraphCMS) الذي يوفر المحتوى (لمدونة) عبر GraphQL. API ومع ذلك ، لا تتطور فقط المكونات التكنولوجية في هذا المجال. مع نمو الفطر بعد هطول الأمطار ، من السهل أيضًا العثور على النشرات الإخبارية والبودكاست في المؤتمرات والمؤثرات والمجتمعات المكرسة لـ GraphQL.

إذا قمت بالتبديل إلى GraphQL - هل أذهب إلى كل شيء؟

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

مساوئ GraphQL

بعد ذلك ، نناقش بعض العيوب المرتبطة باستخدام GraphQL.

تعقيد استعلام GraphQL

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

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

حدود السرعة في GraphQL

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

التخزين المؤقت GraphQL

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

لماذا لا REST؟

GraphQL – REST, . REST – GraphQL, REST?
REST URL , . «», id, , id. GraphQL , . , , , GraphQL , .

, REST. Airbnb. , . REST-, REST- . , , GraphQL API, GraphQL, (, ), (., ).

, GraphQL ; , , , . GraphQL – Facebook , -.

, , REST – . , GraphQL. , GraphQL, - .