قام Phil Sturgeon مؤخرًا بنشر
تغريدة أصابت عشاق GraphQL كثيرًا. تحدثت هذه التغريدة عن كيف أن GraphQL هي ، بحكم تعريفها ، تقنية تتناقض مع جوهر HTTP / 2. حقيقة أن معيار HTTP / 3 قد تم إصداره بالفعل ، وأن مؤلف التغريدة لا يفهم حقًا أولئك الذين ، باختيار GraphQL ، يسلكون مسار عدم التوافق. من أجل فهم أسباب موقف Phil تجاه GraphQL بشكل أفضل ، ألق نظرة على
هذه المادة.
في الوقت نفسه تقريبا ، تم الإعلان عن مشروع
فولكان . تضمنت هذه الرسالة الكلمات: "TL / DR: GraphQL لم تعد بحاجة إليها!". وأخيرًا ، تم نشر
مقالة رائعة لمارك نوتنجهام حول الميزات القوية لـ HTTP / 2 وماذا تعني هذه الميزات لأولئك الذين يصممون واجهة برمجة التطبيقات. شارك Darrel Miller رابطًا لهذه المقالة مع مشتركيه.
ما حدث جعلني أفكر في GraphQL و HTTP / 2. إذا بدأ كل شيء في العمل باستخدام HTTP / 2 (و HTTP / 3) ، فهل هذا يعني أنه ليس لدينا سبب لاستخدام GraphQL؟ أود معرفة ذلك اليوم.
الابتكارات HTTP / 2
للبدء ، دعونا نتعرف على ما يمكن أن تؤثر عليه تقنية HTTP / 2 في قيمة GraphQL في عيون المطورين. HTTP / 2 لديه الكثير لتقدمه. هذا ، على سبيل المثال ، تنسيق ثنائي جديد وضغط محسّن للرأس. ولكن في حالتنا ، يتم لعب الدور الرئيسي عن طريق معالجة تسليم الطلبات والردود عند استخدام HTTP / 2.
فتح اتصال TCP عملية مكلفة. لا يميل العملاء الذين يستخدمون HTTP / 1 إلى تشغيله كثيرًا. لهذا السبب ، نظرًا للحمل الإضافي الكبير على النظام ، غالبًا ما حاول المطورون الحد من عدد الطلبات من خلال اللجوء إلى مجموعة متنوعة من التقنيات. هذا ، على سبيل المثال ، تنفيذ استعلامات الدُفعات ، واستخدام لغات الاستعلام ، ودمج كود CSS / JS في رمز الصفحة ، واستخدام أوراق الرموز المتحركة بدلاً من الصور الفردية ، وما إلى ذلك. في HTTP / 1.1. جرت محاولة لحل بعض هذه المشكلات باستخدام الاتصالات المستمرة ومعالجة البيانات عبر
خطوط الأنابيب . سمحت هاتان التقنيتان للمتصفحات بإرسال طلبات متعددة داخل نفس الاتصال وتلقي الإجابات عليها. وكان عيب نظام تبادل البيانات هذا هو أنه كان يخضع لمشكلة حظر بداية قائمة الانتظار (
حظر رئيس الخط ). يتم التعبير عن هذه المشكلة في حقيقة أن طلب بطيء واحد يمكن أن يؤدي إلى إبطاء معالجة كافة الطلبات التي تليها. اقترح الخبراء الذين عملوا على HTTP / 2 طرق مختلفة لحل هذه المشكلة. مع البروتوكول الثنائي الجديد ، يقدم HTTP / 2 استراتيجية جديدة لتوصيل البيانات. أثناء تفاعل الأنظمة التي تستخدم بروتوكول HTTP / 2 ، يتم فتح اتصال واحد ، يتم في إطاره مضاعفة الطلبات والاستجابات باستخدام مستوى ثنائي جديد مصمم للعمل مع الإطارات ، عندما يكون كل إطار جزءًا من دفق. باستخدام هذه الآلية ، يمكن للعملاء والخوادم إعادة إنشاء تدفق الطلب والاستجابة بناءً على المعلومات المتعلقة بهم الموجودة في الإطارات. هذا يسمح HTTP / 2 لدعم معالجة العديد من الطلبات التي يتم تنفيذها داخل اتصال واحد بشكل
فعال للغاية.
لكن هذا ليس كل شيء. يحتوي HTTP / 2 على مفهوم جديد يسمى Server Push. إذا لم تدخل في التفاصيل ، فيمكننا القول أن هذه التكنولوجيا تسمح للخوادم بإرسال البيانات إلى العملاء مقدمًا ، وذلك قبل أن يطلب العملاء هذه البيانات. الأمثلة الأكثر وضوحًا لهذا السلوك هي إرسال أوراق أنماط وموارد JavaScript إلى العملاء مقدمًا. في عملية توليد استجابة لطلب HTTP ، يستطيع الخادم معرفة أن بعض ملفات CSS مطلوبة لتقديم صفحة HTML ، واكتشف مقدمًا مسبقًا أن العميل سيتصل به قريبًا للحصول على هذا الملف. يسمح هذا للخادم بإرسال الملف المحدد إلى العميل حتى قبل أن يطلبه العميل. هذه هي الطريقة التي يعمل بها مشروع
Vulcain المذكور أعلاه ، باستخدام هذه التكنولوجيا لتنظيم التحميل الفعال للموارد ذات الصلة.
لذلك ، في حين أن كل شيء واضح. ولكن ما علاقة كل هذا بـ GraphQL؟
GraphQL: استعلام واحد يحل جميع المشكلات
ترجع تقنية GraphQL جزئيًا إلى جاذبيتها لأنها تساعد المطورين على التعامل مع العيوب النموذجية لاتصالات HTTP / 1.
هذا هو السبب في أن GraphQL تتيح للعملاء ، في جلسة واحدة ، التواصل مع الخادم ، لتلبية الطلبات لتلقي أي شيء تقريبًا. يمكن أن يتناقض هذا مع Hypermedia-API ، عند استخدام ما تحتاج إليه عادةً لتنفيذ العديد من طلبات الشبكة (في بعض الأحيان ، ومع ذلك ، يمكن أن يؤدي
التخزين المؤقت إلى تحسين الموقف).
تعد القدرة على تلقي موارد متعددة ضمن استعلام واحد إحدى نقاط القوة في GraphQL ، والتي يجذب منشئو هذه التقنية انتباه المستخدمين المحتملين إليها.كثير من أولئك الذين يقولون أن لا أحد يحتاج إلى تقنية GraphQL مع ظهور HTTP / 2 يعني هذا الاحتمال. باستخدام واجهات برمجة التطبيقات الدفعية ، أصبحت لغات الاستعلام (مثل GraphQL) ، وتحسين العلاقات ، وحتى إنشاء نقاط نهائية موسعة ، أقل جاذبية من ذي قبل. الشيء هو أن "تكلفة" أداء الاستعلامات تصبح صغيرة. وهذا صحيح. ولكن هل هذا هو السبب في أننا نستخدم GraphQL فقط؟ لا أعتقد ذلك.
ربما الحقيقة هي أن الآن لا تزال الأيام الأولى لعملاء HTTP / 2 وبعض تطبيقات الخادم؟
لا أظن أن السؤال المطروح في عنوان هذا القسم بمثابة تفسير يستحق حقيقة أننا لا نزال نستخدم GraphQL على نطاق واسع. لكن الأمر يستحق الذكر. يعد استخدام HTTP / 2 على مستوى التطبيق في بعض الأنظمة الإيكولوجية تحديًا بعيدًا عن الحل. ابحث عن ، على سبيل المثال ، الكلمات "Rack / Rails over HTTP / 2." سيكون من المثير للاهتمام. الشيء هو أن العديد من أجزاء الخادم من التطبيقات مبنية باستخدام نموذج الطلب / الاستجابة. ونتيجة لذلك ، فإن التحول إلى مفهوم تدفقات HTTP / 2 ليس بهذه البساطة. خاصة - في حالة بعض الأطر. لكن هذا عذر لا يستحق العناء ، فالعديد من النظم الإيكولوجية تدعم تمامًا مخطط التفاعل هذا بين العملاء والخوادم ، ومن الناحية النظرية ، لا يزال يتعين علينا السعي لتحسين هذا التفاعل. (يدعم معظم الوكلاء هذا أيضًا ، لكن ليس من السهل تنظيم شيء مثل إرسال البيانات إلى عميل بمبادرة الخادم إذا كان تطبيق الخادم عالقًا في الماضي باستخدام نمط طلب / استجابة).
GraphQL هو أكثر من تقليل وقت استلام البيانات ونقلها ، أو تحسين كمية المعلومات المرسلة
على الرغم من أن تقليل وقت تلقي ونقل البيانات وتحسين كمية المعلومات المرسلة هي نقاط القوة في GraphQL التي نسمع عنها باستمرار ، إلا أن هذه التكنولوجيا توفر لنا أكثر من ذلك بكثير.
تكمن قوة تقنية GraphQL في تركيزها على أنظمة العملاء. العميل هو البيئة التي تجعل GraphQL بها العديد من التنازلات. في السنوات الأخيرة ، أزعج هذا الكثير. لذلك ، كتب دانييل جاكوبسون العديد من المقالات الجيدة حول بعض من هذه المشاكل قبل 5-7 سنوات.
هنا وهناك - زوجين من منشوراته. يقول أحدهم: "واجهات برمجة تطبيقات REST الخاصة بنا ، على الرغم من أنها قادرة على معالجة الطلبات العامة ، لا يتم تحسينها لأي من هذه الطلبات."
يرجى ملاحظة أن هذه الفكرة صالحة ليس فقط عند تطبيقها على تقنية REST. غالبًا ما يتعين على تطبيقات العميل تنفيذ طلبات خادم أكثر مما يريد مطوروها. يجب أن تتعامل هذه التطبيقات مع تلقي البيانات غير الضرورية من الخوادم. هذا هو أكثر حول تصميم واجهات برمجة التطبيقات التي سيكون من الجيد إنشاء بحيث تدعم العديد من الاستخدامات المختلفة. الطريقة المعتادة لحل هذه المشكلة هي أن يكون منطق العميل أقرب ما يكون إلى منطق الخادم. مثال على هذا النهج هو محولات عميل Netflix المذكورة في مقالة 2012
هذه . منذ ذلك الحين ،
تحولت بعض فرق Netflix إلى GraphQL. ويهدف نمط
BFF أيضا إلى حل مثل هذه المشاكل.
تعمل تقنية GraphQL على تغيير مفهوم الحدود بين العميل والخادم ، مما يساعدنا في إنشاء أنظمة خادم يمكن أن تتضمن معلومات حول كيفية استخدامها من قبل العملاء. يتجلى ذلك بوضوح عند استخدام تقنية الطلبات
المستمرة ، حيث أننا هنا نتحدث ، في جوهرها ، عن موارد الخادم التي تم إنشاؤها بمبادرة من العميل.
عند التفكير في مدى ملاءمة GraphQL في عالم HTTP / 2 ، تذكر أننا نتحدث عن تجريد الخادم. يمكن أن يؤدي دعم مجموعة متنوعة من حالات استخدام بيانات الخادم إلى مشاكل في واجهات برمجة التطبيقات التقليدية المستندة إلى نقطة النهاية. يسمح GraphQL لمن يدعم API بالتركيز على منح مستخدمي هذه API مجموعة واسعة من الميزات. في الوقت نفسه ، لا يمكن لمالكي واجهة برمجة التطبيقات القلق بشأن الحمل المتزايد على العملاء الحاليين ، وأن دعم واجهة برمجة التطبيقات سيصبح أكثر تعقيدًا بسبب الحاجة إلى دعم العديد من الموارد المختلفة. (دعم العديد من الموارد المختلفة له عيوبه. لذا ، فإن مثل هذه المخططات تعقد تحسين الأداء. لا يتم تخزين هذه الموارد دائمًا بشكل جيد. واجهات برمجة التطبيقات التي يمكن ضبطها بشدة تواجه نفس المشكلات).
أنظمة العملاء وتطوير GraphQL
في هذه المقالة ، أتحدث بشكل رئيسي عن الخوادم ، ولكن من المهم أن نتذكر أن مطوري العملاء مغرمون جدًا بتقنية GraphQL. إذا قمت بدمج شظايا GraphQL مع النهج المكون من الأطر الأمامية الحديثة ، فستحصل على تجريد مدهش تمامًا. ومرة أخرى ، إذا أضفنا استعلامات ثابتة هنا ، فيمكننا القول إن GraphQL تجعل الحياة أسهل لمطوري أنظمة العملاء.
GraphQL هو نظام شامل مع ميزات رائعة
GraphQL ليس شيئًا له قدرات فريدة تمامًا. هناك بدائل لهذا النظام. مخطط مطبوع؟ نفس الشيء مع OpenAPI! خادم التجريدات التي تدعم مختلف حالات استخدام العميل؟ هذا يمكن تنفيذه بعدة طرق. التأمل؟ يتيح استخدام Hypermedia للعملاء اكتشاف الإجراءات وبدء العمل مع الكيان الجذر. أداة GraphiQL لذيذة؟ أنا متأكد من إنشاء شيء مشابه لـ OpenAPI. يمكن دائمًا إعادة إنشاء إمكانيات GraphQL باستخدام تقنيات أخرى. ومع ذلك ، GraphQL هو نظام كلي. هذا ما يجذب جمهورًا كبيرًا من المطورين إلى GraphQL الذين يسعدهم استخدام هذا النظام. أظن أن هذا أحد أسباب الانتشار السريع لـ GraphQL وتطويره. بالإضافة إلى ذلك ، نظرًا لأن توثيق GraphQL-API موثق جيدًا ، فإن مكتبات GraphQL المصممة بلغات مختلفة تكون ذات جودة عالية وشعبية.
لا تزال الشبكات عاملاً مقيدًا (أو ربما ستكون دائمًا هكذا؟)
إليكم فكرة أخرى أريد أن أتطرق إليها. هناك شعور بأن الشبكة ، عندما يتعلق الأمر بالعمل مع واجهة برمجة التطبيقات ، ستلعب دائمًا دور بعض العوامل المحددة. لا يهم مدى سرعة طلبات الشبكة. هذا هو السبب في أننا لا نقوم بتصميم واجهات برمجة التطبيقات على الويب بنفس طريقة الكائنات العادية المستخدمة في لغات البرمجة المختلفة.
هنا ، على سبيل المثال ، نتحدث عن سبب عدم ملائمة الواجهات ذات المستوى العالي من التفاصيل لإنشاء أنظمة مصممة للعمل عن بعد معهم.
في حين أن HTTP / 2 يشجع بالتأكيد على تنفيذ الطلبات بدقة عالية ، أعتقد أن هناك بعض المقايضات التي يتعين تقديمها هنا.
يمكن HTTP / 2 مساعدة GraphQL؟
لذلك ، توفر GraphQL للمطور الكثير من الأدوات المهمة والمفيدة ، ولكن HTTP / 2 هي أيضًا تقنية رائعة. دعونا ننظر إلى المستقبل والتفكير في الفوائد التي يمكن أن تستفيد أنظمة GraphQL من استخدام HTTP / 2. على سبيل المثال ، قد يبدو كالتالي:
query { viewer { name posts(first: 100) @stream { title } } }
اتضح أنه يمكننا استخدام التجريد من جانب الخادم لـ GraphQL ، ولغة الاستعلام التعريفي لهذه التكنولوجيا ، وفي الوقت نفسه استخدام إمكانات تدفقات HTTP / 2. أعتقد أن مآخذ الويب تستخدم هنا. ما زلت بحاجة لمعرفة ذلك ، لكنني متأكد من أن العديد منهم يستكشفون بالفعل توجيهات GraphQL مثل
@defer و
@stream و
@stream .
النتائج
HTTP / 2 هي تقنية رائعة (والأمثلة الواردة
هنا ليست سوى نوع من المعجزة). لا يمكن اعتبار GraphQL سوى تقنية تقلل من عدد جلسات اتصال خادم العميل ، أو تساعد في تحسين حجم البيانات المرسلة. إذا كان الأمر كذلك ، فسيكون أي شخص يرى GraphQL من منظور مماثل سعيدًا جدًا باستخدام واجهات برمجة التطبيقات (APIs) بناءً على إمكانات HTTP / 2. ومع ذلك ، إذا رأيت في GraphQL مجموعة من التقنيات التي توفر للمطور الكثير من الأشياء المفيدة ، يصبح من الواضح أن قوة GraphQL لا تقتصر على الإطلاق على تحسين استخدام موارد الشبكة وتوفير حركة المرور.
أعزائي القراء! إذا كنت تستخدم تقنية GraphQL ، فيرجى إخبارنا بما لا يعجبك أكثر في هذا الأمر.
