في المقالة السابقة، فحصنا بروتوكولات التشغيل الآلي الحالية، وهي WebDriver "كلاسيكي" وبروتوكول أدوات مطوّري البرامج في Chrome (CDP)، بالإضافة إلى مزاياها والقيود المرتبطة بها.
أدخِل WebDriver BiDi، وهو مستقبل التشغيل الآلي للمتصفح. وهو بروتوكول عادي جديد من بروتوكولات التشغيل الآلي للمتصفِّح قيد التطوير حاليًا، ويهدف إلى الجمع بين أفضل ما في WebDriver "الكلاسيكي" وCDP. تعد تقنية WebDriver BiDi بتوفير اتصال ثنائي الاتجاه، ما يجعلها سريعة بشكل تلقائي، ويتم تزويدها بعنصر تحكم منخفض المستوى.
| WebDriver BiDi | |
|---|---|
| WebDriver "كلاسيكي" | بروتوكول أدوات مطوّري البرامج في Chrome (CDP) |
| أفضل توافق عبر المتصفحات | مراسلة سريعة ثنائية الاتجاه |
| معيار W3C | توفر تحكمًا منخفض المستوى |
| تصميم يراعي الاختبار | |
تكمن رؤية WebDriver BiDi في السماح لك بكتابة الاختبارات باستخدام أي من أدواتك المفضّلة وبرمجتها في أي متصفّح أو برنامج تشغيل، ما يمنحك المرونة الكاملة.
توحيد المقاييس
تتكوّن WebDriver BiDi Working Group من مجموعة متنوعة من مورّدي المتصفّحات ومشاريع التشغيل الآلي للمتصفّحات مفتوحة المصدر وشركات توفير حلول التشغيل الآلي للمتصفّحات. ويضمن هذا التعاون مستقبلًا واعدًا لأتمتة المتصفّحات.
يتم تنفيذ العمل غالبًا في مستودع جيت هب هذا. هناك اجتماعات شهرية مع جميع موردي المتصفح الرئيسيين للإبلاغ عن التقدم الفعلي ومناقشة التفاصيل المثيرة للجدل وغير معروفة. تتأكد مجموعة العمل بين الشركات من أن القرارات تتماشى مع جميع الأطراف المعنية.
إن إنشاء بروتوكول جديد وتنفيذه ليس بالأمر الهين. ويتطلب جهودًا منسّقة من مختلف البائعين الذين يتعاونون ويعملون معًا. وتتضمّن هذه العملية ما يلي:
- المواصفات: طلب عملية تعليقات (RFC) لجمع الملاحظات حول الاقتراح.
- التحقّق: يتضمّن هذا القسم سلسلة من الاختبارات التي يمكن إجراؤها على مختلف المنصّات، والتي تكون مصدر الحقائق لجميع عمليات التنفيذ.
- التنفيذ: تنفّذ المتصفّحات البروتوكولات وفقًا للمواصفات وتجتاز اختبارات التحقّق.
التحديات
في هذا القسم، سنتناول تحديات تنفيذ WebDriver BiDi، حيث إنّه يسعى إلى تحقيق التوازن بين التوافق وسهولة الاستخدام وقابلية التنفيذ.
ما وراء استنساخ CDP: تبني التوافق بين المتصفحات
لا يمكن نسخ CDP، مع العناصر الخاصة بـ Chrome وأدوات مطوّري البرامج، مباشرةً في مواصفات WebDriver BiDi. لن يكون استخدام CDP كما هو غير ممكن في المتصفّحات الأخرى، ما يؤدي إلى عرض مواصفة توثّق فقط كيفية تنفيذ ذلك بدون جدوى.
ضمان بطء وقت الاستجابة
يجب تصميم WebDriver BiDi للتعامل مع وقت الاستجابة الطويل بدون التأثير في الأداء. في CDP، يكون وقت الاستجابة منخفضًا لأنّ العميل والخادم يعملان دائمًا على نفس الجهاز الفعلي، ولكن هذا ليس هو الحال في WebDriver BiDi. وبالتالي، يجب على WebDriver BiDi تقليل عدد عمليات الإرسال والاستقبال المطلوبة بين العميل والخادم.
إعطاء الأولوية لهندسة الهندسة المعمارية في BiDi
على الرغم من أنّه لا يُتوقّع من المطوّرين إنشاء برامج WebDriver BiDi من البداية، إلا أنّه من الضروري تجنُّب تعقيد البروتوكول بشكلٍ مفرط. ولن يكون تطبيق BiDi معقّدًا للغاية تحديًا فحسب، بل يصعُب استخدامه أيضًا، ما يعيق الاعتماد والاستخدام.
التأكّد من قابلية تنفيذ 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 BiDi: كيف يمكنك المساعدة
هل أنت متحمّس بشأن مستقبل التشغيل الآلي للمتصفِّح باستخدام WebDriver BiDi؟ في ما يلي كيفية إظهار الدعم لك:
- الانضمام إلى برنامج المختبِرين في مرحلة مبكرة والمساعدة في تطوير منصة WebDriver BiDi
- خبر سار: شارِك المشروع على وسائل التواصل الاجتماعي باستخدام الهاشتاغ #WebDriverBiDi.
- طلب الدعم: قدِّم طلب ميزة أو تحقّق من أدواتك المفضّلة بشأن خطط استخدام WebDriverBiDi.
- المشاركة في طلب RFC، وتقديم ملاحظات حول واجهات برمجة التطبيقات.
الأسئلة الشائعة
هل سيحلّ WebDriver BiDi محلّ بروتوكول أدوات مطوّري البرامج في Chrome (CDP)؟
لا، ستواصل المتصفّحات المستندة إلى Chromium استخدام بروتوكول CDP لأغراض تصحيح الأخطاء، في حين أنّ WebDriver BiDi هو المواصفات الجديدة لتلبية احتياجات الاختبار باستخدام واجهة برمجة تطبيقات أكثر سهولة.
بما أنّ Puppeteer يستخدم CDP، هل يعني ذلك أنّه سيتم إيقاف Puppeteer نهائيًا؟
لا، ومع ذلك، سيعمل WebDriver BiDi على تفعيل Puppeteer ليصبح أداة مبرمَجة على جميع المتصفّحات.
هل لديك خارطة طريق عامة؟
نعم، يمكنك الانتقال إلى خطة تحقيق الأهداف على GitHub.