في مقالتنا السابقة، فحصنا بروتوكولات التشغيل الآلي الحالية، وهي WebDriver "الكلاسيكي" وChrome DevTools Protocol (CDP)، بالإضافة إلى مزاياها والقيود المفروضة عليها.
نعرّفك على WebDriver BiDi، مستقبل التشغيل الآلي للمتصفّح. وهو بروتوكول تشغيل مبرمَج عادي جديد للمتصفّح قيد التطوير حاليًا، ويهدف إلى الجمع بين أفضل ما في WebDriver "الكلاسيكي" وCDP. يضمن WebDriver BiDi الاتصال باتجاهَين، ما يجعله سريعًا تلقائيًا، كما أنّه مزوّد بعناصر تحكّم من المستوى الأدنى.
| WebDriver BiDi | |
|---|---|
| WebDriver "الكلاسيكي" | بروتوكول "أدوات مطوّري البرامج في Chrome" (CDP) |
| أفضل توافق مع جميع المتصفّحات | مراسلة سريعة ثنائية الاتجاه |
| معيار W3C | توفير التحكّم على مستوى منخفض |
| مصمّمة للاختبار | |
إنّ الهدف من WebDriver BiDi هو السماح لك بكتابة الاختبارات باستخدام أي من أدواتك المفضّلة وبرمجة هذه الاختبارات في أي متصفّح أو برنامج تشغيل، ما يمنحك المرونة الكاملة.
توحيد المقاييس
تتألف مجموعة عمل WebDriver BiDi من مجموعة متنوعة من مورّدي المتصفّحات ومشاريع التشغيل الآلي للمتصفّحات ذات المصدر المفتوح والشركات التي تقدّم حلول التشغيل الآلي للمتصفّحات. يضمن هذا التعاون مستقبلًا واعدًا للتشغيل الآلي للمتصفّح.
يتم تنفيذ العمل في مستودع GitHub هذا. يتم عقد اجتماعات شهرية مع جميع مورّدي المتصفّحات الرئيسيين لعرض مستوى التقدّم الفعلي ومناقشة تفاصيل غير معروفة أو قابلة للجدل. تتأكّد مجموعة العمل المشتركة بين الشركات من أنّ القرارات متوافقة مع جميع الجهات المعنية.
إنّ وضع بروتوكول جديد وتنفيذه ليس بالأمر السهل. ويتطلّب ذلك جهودًا متضافرة من مورّدين مختلفين يتعاونون معًا. تتضمّن العملية ما يلي:
- المواصفات: عملية طلب التعليقات (RFC) لجمع الملاحظات حول الاقتراح
- التحقّق: سلسلة من الاختبارات التي يمكن إجراؤها على جميع المنصات، وتعمل كمصدر دقيق لجميع عمليات التنفيذ.
- التنفيذ: تُنفِّذ المتصفّحات البروتوكولات وفقًا للمواصفات وتجتاز اختبارات التحقّق.
التحديات
في هذا القسم، سنتناول بالتفصيل تحديات تنفيذ WebDriver BiDi، لأنّه يسعى إلى تحقيق التوازن بين التوافق وسهولة الاستخدام وقابلية التنفيذ.
ميزات إضافية غير متوفّرة في منصّة CDP: التوافق مع جميع المتصفّحات
لا يمكن تكرار بروتوكول CDP، مع عناصره الخاصة بمتصفّح Chrome و"أدوات مطوّري البرامج في Chrome"، مباشرةً في مواصفات WebDriver BiDi. سيكون من غير الممكن تنفيذ إطار عمل CDP كما هو في المتصفّحات الأخرى، ما يجعل المواصفات التي توثّق كيفية تنفيذ ذلك غير مجدية.
ضمان وقت استجابة سريع
يجب تصميم WebDriver BiDi للتعامل مع وقت الاستجابة العالي بدون التأثير في الأداء. في CDP، يكون وقت الاستجابة منخفضًا لأنّ العميل والخادم يتم تشغيلهما دائمًا تقريبًا على الجهاز المادي نفسه، ولكنّ هذا ليس هو الحال في WebDriver BiDi. لذلك، يجب أن يعمل WebDriver BiDi على تقليل عدد عمليات النقل المطلوبة بين العميل والخادم.
منح الأولوية لسهولة الاستخدام في اتجاه الكتابة من اليمين إلى اليسار
على الرغم من أنّه لا يُتوقّع من المطوّرين إنشاء عملاء WebDriver BiDi من الصفر، من المهم تجنُّب التعقيد المفرط في البروتوكول. إنّ إتاحة ميزة "الاتجاهين" بشكل معقّد للغاية لن يصعّب تنفيذها فحسب، بل سيصعّب أيضًا استخدامها، ما يعرقل عملية الاعتماد والاستخدام.
ضمان إمكانية تنفيذ ميزة الكتابة من اليمين إلى اليسار
يجب أن يكون WebDriver BiDi قابلاً للتنفيذ بشكل واقعي، مع مراعاة القيود المفروضة على المتصفحات المختلفة. على سبيل المثال، قد يؤدي الاحتفاظ بجميع كائنات JavaScript التي تم عرضها على العملاء من خلال BiDi إلى تسرُّب الذاكرة، في حين أنّ عدم الاحتفاظ بأي منها قد يعرقل تصحيح الأخطاء والتفاعل مع JavaScript للصفحة. من الضروري تحقيق التوازن الذي يتيح التشغيل الآلي للمتصفّح بفعالية بدون التأثير سلبًا في الأداء.
التغلب على التحديات
في هذا القسم، سنناقش الاستراتيجيات المستخدَمة لمواجهة تحديات تنفيذ WebDriver BiDi.
وضع النماذج بسرعة
إنّ معالجة مشكلة قابلية التنفيذ أمرٌ بالغ الأهمية لنجاح ميزة BiDi. لتسريع التقدّم في المواصفات والاختبارات، اتّبعنا نهجًا لإنشاء النماذج الأولية بسرعة باستخدام NodeJS. لا يتيح لنا ذلك تجربة حلول مختلفة فحسب، بل يسهّل أيضًا تطوير اختبارات منصّة الويب.
التصميم مع وضع الأداء في الاعتبار
يستند قرار التصميم هذا إلى الأداء، لأنّ وقت الاستجابة يكون مرتفعًا في WebDriver BiDi في بعض الحالات. على سبيل المثال، عند استرداد معرّف عنصر وقيمة من المتصفّح، لا يتطلّب WebDriver BiDi سوى رحلة ذهاب وإياب واحدة، في حين يتطلّب CDP رحلتَين. ويعود السبب في ذلك إلى أنّ WebDriver BiDi يمكنه عرض كلّ من المعرّف والقيمة في استجابة واحدة (يجب ألا تكون النتيجة قابلة للتسلسل باستخدام JSON)، في حين يجب أن يعرض CDP كلّ منهما بشكل منفصل.
التركيز على اختبارات منصّة الويب (WPT)
تلعب اختبارات منصّة الويب دورًا مهمًا في أعمال BiDi. يُعدّ WPT مرجعًا موثوقًا لجميع عمليات التنفيذ، حيث يتناول حاليًا WebDriver "الكلاسيكي" وWebDriver BiDi. تم تصميم هذه الاختبارات ليتم إجراؤها واجتيازها في عمليات التنفيذ المختلفة، ما يضمن تنفيذ بروتوكول متوافق على جميع المتصفّحات، وهو أمر حيوي لنجاح WebDriver BiDi. اطّلِع على أحدث نتيجة WPT في لوحة البيانات.
ما هي الخطة والتقدّم الحالي؟
اطّلِع على خارطة طريق WebDriver BiDi للتعرّف على اتجاه المشروع. لا تزال الخريطة قيد التطوير وتتغيّر باستمرار.
يُرجى الرجوع إلى أحدث اختبارات منصة الويب لمعرفة حالة التنفيذ على مستوى المتصفّحات، لأنّها تُعدّ مصدر المعلومات الصحيحة.
اطّلِع على معالم المشروع الرئيسية لمتابعة مستوى تقدّمه.
تعرَّف على الإنجازات التي حقّقناها في عام 2023 وابقَ على اطّلاع على آخر التطورات.
إتاحة ميزة "الاتجاهين" في WebDriver: كيفية المساعدة
هل يهمّك مستقبل التشغيل الآلي للمتصفّح باستخدام WebDriver BiDi؟ في ما يلي كيفية إظهار دعمك:
- يمكنك أن تكون أحد أوائل المختبِرين والمستخدِمين، ما يساعد في وضع أسس مستقبل WebDriver BiDi.
- خبر سار: شارِك المشروع على وسائل التواصل الاجتماعي باستخدام الهاشتاغ #WebDriverBiDi.
- طلب الدعم يمكنك إرسال طلب ميزة أو التواصل مع أدواتك المفضّلة لمعرفة خططها بشأن استخدام WebDriverBiDi.
- المشاركة في طلب الحصول على معيار RFC، وتقديم ملاحظات حول واجهات برمجة التطبيقات
الأسئلة الشائعة
هل سيحل WebDriver BiDi محلّ Chrome DevTools Protocol (بروتوكول أدوات مطوّري البرامج في Chrome)؟
لا، ستواصل المتصفّحات المستندة إلى Chromium استخدام CDP لأغراض تصحيح الأخطاء، في حين أنّ WebDriver BiDi هي المواصفة الجديدة لتلبية احتياجات الاختبار باستخدام واجهة برمجة تطبيقات أكثر ملاءمةً.
بما أنّ Puppeteer يستخدم إطار عمل CDP، هل يعني ذلك أنّه سيتم إيقاف Puppeteer نهائيًا؟
لا، ولكن سيتيح WebDriver BiDi لـ Puppeteer أن تصبح أداة برمجة مهام على جميع المتصفّحات.
هل لديك خارطة طريق علنية؟
نعم، يمكنك زيارة خارطة الطريق على GitHub.