WebDriver BiDiとは？双方向ブラウザ自動化

Scrapeless Scraping Browserは、プロトコルとイベント要件がサービスに対して検証された自動化クライアントのための管理されたブラウザインフラストラクチャを提供します。

WebDriver BiDiはブラウザ制御にライブイベントチャネルを追加します

従来のWebDriverは、離散的なクライアントリクエストとリモートレスポンスに基づいて構築されています。そのモデルは、ナビゲーション、入力、要素、ウィンドウ、クッキー、スクリーンショット、スクリプトをうまく処理しますが、現代のブラウザはイベント駆動型です。ネットワークリクエストが始まり、終わり、ログが表示され、ブラウジングコンテキストが開いたり閉じたりし、ダイアログが表示され、ダウンロードが開始され、スクリプトが次のクライアントコマンドとは独立して実行されます。WebDriver BiDiは持続的な双方向接続を作成し、クライアントがこれらの変化にサブスクライブし、それが発生するにつれて受信できるようにします。

W3C WebDriver BiDi仕様 WebDriver BiDiをユーザーエージェントのリモート制御のメカニズムとして定義し、双方向通信がブラウザDOMのイベント性により適していることを説明しています。この文書はW3C推奨トラックにありますが、作業草案のままです。したがって、プロダクションデザインは最新の仕様と現在の実装を移動するサーフェスとして扱い、必要なすべてのモジュールを検証する必要があります。

コマンド、結果、エラー、およびイベントは1つのWebSocketを共有します。

BiDiメッセージは、モジュールコマンドのようなメソッドを特定し、パラメータを持ちます。コマンドにはクライアントが制御する識別子があり、複数の操作が同時に実行され、順不同で終了しても結果やエラーが一致します。イベントはメソッド名とデータを持ちますが、特定のコマンドへの応答ではありません。クライアントはイベント名にサブスクライブし、オプションでブラウジングやユーザコンテキストにスコープを付け、信号がもはや必要でなくなった場合はサブスクリプションを解除できます。

MDN WebDriver BiDiリファレンス BiDiをWebSocketベースのイベント駆動型WebDriverのバリアントとして説明し、モジュール、コマンド、およびイベントのリファレンスページを提供します。持続接続はクライアントアーキテクチャを変えます: メッセージディスパッチ、サブスクリプションのライフタイム、順序、バッファリング、およびクリーンアップが明示的な問題となります。クライアントはイベント到着順序だけがアプリケーションの最終ビジネス状態を証明するものと考えてはなりません。

• モジュール。 ネームスペースは、セッション、ブラウザ、ブラウジングコンテキスト、ネットワーク、スクリプト、ログ、ストレージ、または入力のような関連するコマンドとイベントをグループ化します。
• コマンド。 非同期クライアントリクエストは識別子、メソッド、およびパラメータを持ち、後に一致した結果またはエラーを受け取ります。
• イベント。 ブラウザ起源の通知は新しいクライアントリクエストに結び付けることなく、サブスクリプションされたアクティビティを報告します。
• サブスクリプション。 クライアントはリモート側に発行してほしいイベント名とオプションのコンテキストスコープを選択します。
• コンテキストと領域。 ブラウジングコンテキストはタブまたはフレームを表し、スクリプト領域はそれらのコンテキスト内の実行環境を表します。

BiDiはWebDriverセッションまたはBiDi専用パスを通じて開始できます。

クライアントはWebDriverセッションを作成する際にWebSocket URL機能を要求できます。サポートされているリモート側は接続URLを返し、セッションをBiDi対応としてマークします。仕様はまた、実装が帯域外接続URLを介してBiDi専用セッションを公開することを許可します。接続後、クライアントはサブスクリプションを管理し、モジュールコマンドを発行できます。実際のスタートアップパスはブラウザ、ドライバ、クライアントライブラリ、リモートサービスに依存します。

公式Puppeteer WebDriver BiDiサポートガイド PuppeteerがChromeとFirefoxのためにWebDriver BiDiをどのように使用しているのかを説明し、サポートされていない機能は明示的なエラーを引き起こすことを指摘しています。これは徐々に実装される実用的な例です：クライアントは、そのスタックでBiDiがまだカバーしていないChrome機能のためにCDPを保持しつつ、有用なBiDiパスを公開することができます。アーキテクチャは、部分的なサポートを完全なプロトコルの互換性として提示せずに、能力チェックやスコープ付きフォールバックを許可する必要があります。

WebDriver Classic、WebDriver BiDi、およびCDPは異なる目標を持っています。

これらのプロトコルは重複していますが、輸送、イベントモデル、標準化の範囲、および実装の成熟度が異なります。

双方向イベントが自動化設計を変更する場所

BiDiは、ブラウザ起源のアクティビティが偶発的なデバッグデータではなく、結果または同期モデルの一部であるときに価値があります。

仕様と実装はまだ進化しています

W3Cの作業草案は変更される可能性があり、実装は一般的に1つのモジュールまたはコマンドを順次追加します。ブラウザサポート、ドライバサポート、クライアントバインディング、およびリモートサービスは異なるスケジュールで進行する可能性があります。したがって、公開の互換性主張には、内部のエンジニアリングノートに日付と機能リストが必要です。エバーグリーンウィキは脆弱なバージョンテーブルを避けるべきですが、アプリケーションが依存する正確な購読、コマンド、パラメータ、および結果の形状をテストしてください。

WebDriver BiDiモジュールに関するMDNリファレンス BiDiモジュールとそのコマンドおよびイベントの名前空間のリスト。リストは発見には役立ちますが、すべてのブラウザがすべてのエントリを実装している証明ではありません。実装結果、ブラウザのリリース情報、およびクライアントライブラリのサポートテーブルを確認し、次に本番環境で互換性に焦点を当てたスモークテストを実行してください。

WebDriver BiDi採用チェックリスト

プロトコルラベルによるのではなく、必要な機能によってBiDiを採用します。テストは、輸送、コマンド、イベント、コンテキスト、およびクリーンアップの動作を端から端まで証明する必要があります。

1. 必要なモジュールの名前を付けてください。 ワークフローが必要とする正確なセッション、ブラウザ、ブラウジングコンテキスト、ネットワーク、スクリプト、ログ、ストレージ、入力、または他のコマンドとイベントをリストしてください。
2. スタートアップパスを確認してください。 クライアントがクラシックセッションを通じてwebSocketUrlを要求するか、BiDi専用エンドポイントに接続するか、フレームワークに交渉を管理させるかを確認します。
3. 購読をテストしてください。 意図したイベントを購読および購読解除し、関連するコンテキストにスコープを設定し、無関係なセッションがハンドラーにイベントを漏らさないことを確認してください。
4. 並行処理を処理します。 結果をコマンド識別子と一致させ、順不同の完了を許可し、長時間実行されるコマンド中にイベントが到着したときのメッセージ配信の動作を定義します。
5. コンテキストのライフタイムをモデル化します。 タブ、フレーム、ユーザーコンテキスト、およびスクリプト領域を明示的に追跡し、イベントやリモート参照がそのコンテキストが破棄された後に適用されないようにします。
6. バウンドイベントボリューム。 必要なイベントタイプのみを選択し、早期にフィルタリングし、バッファリングとバックプレッシャーを定義し、無関係な個人データや秘密データを含むペイロードの保持を避けます。
7. サポートされているパスを保持します。 選択されたブラウザとクライアントから欠落している負荷耐性のある機能のために、クラシックWebDriverまたはCDPアダプタを保持し、境界を明確にするテストを実施します。
8. アップグレードを再検証します。 ブラウザ、ドライバ、クライアントライブラリ、リモートサービス、または仕様実装が変更されたときにプロトコルスモークテストを実行します。

WebDriver BiDiと管理されたブラウザインフラ

管理されたブラウザサービスはリモートサイドをホストできるが、クライアントアプリケーションが別の場所で実行される場合、エンドポイントプロトコルとサポートされているモジュールは明示的に確認する必要があります。Scrapeless Scraping Browserは、サポートされている自動化クライアントのためのリモートブラウザインフラを提供します。現在のドキュメントとライブ互換性テストがそのパスを確認しない限り、BiDiエンドポイントとして説明すべきではありません。

サービスドキュメントを使用して、サポートされているクライアントと接続モデルを特定し、採用前にすべての必要なイベントとコマンドをテストします。現在の Scrapeless Scraping Browser製品概要, Scrapeless Scraping Browserのはじめにドキュメント、そして Scrapelessの価格 運用モデルを選択する前に。

結論：BiDiはブラウザイベントを標準のパスに取り込みます

WebDriver BiDiは、WebDriverファミリーへの永続的で双方向のイベント駆動型接続を追加します。モジュールはコマンドとイベントを整理し、サブスクリプションはブラウザの出力を制御し、非同期コマンド識別子は複数の操作を同時に実行できるようにします。このモデルは、従来のポーリング単独よりもコンソール、ネットワーク、コンテキスト、スクリプトの活動により適しています。

慎重に導入してください。仕様は作業草案のままで、サポートは機能ごとであり、CDPまたは従来のWebDriverには依然として必要な操作がある可能性があります。小さな互換性スイートがブラウザ、ドライバー、クライアント、およびリモートサービス間の実際の契約を定義する必要があります。