WebDriver BiDi là gì? Tự động hóa trình duyệt hai chiều

Trình duyệt thu hoạch không cần scrap cung cấp cơ sở hạ tầng trình duyệt được quản lý cho các khách hàng tự động hóa mà các yêu cầu giao thức và sự kiện đã được xác minh với dịch vụ.

WebDriver BiDi thêm một kênh sự kiện thời gian thực vào điều khiển trình duyệt

WebDriver cổ điển được xây dựng xung quanh các yêu cầu khách hàng riêng lẻ và các phản hồi từ xa. Mô hình đó xử lý tốt việc điều hướng, nhập liệu, phần tử, cửa sổ, cookie, chụp màn hình và kịch bản, nhưng trình duyệt hiện đại dựa trên sự kiện. Các yêu cầu mạng bắt đầu và kết thúc, nhật ký xuất hiện, các ngữ cảnh của truy cập mở hoặc đóng, hộp thoại hiển thị, tải xuống bắt đầu và kịch bản chạy độc lập với lệnh khách hàng tiếp theo. WebDriver BiDi tạo ra một kết nối hai chiều liên tục để khách hàng có thể đăng ký những thay đổi đó và nhận được chúng khi chúng xảy ra.

Tài liệu của W3C về WebDriver BiDi định nghĩa WebDriver BiDi như một cơ chế để điều khiển từ xa các tác nhân người dùng và giải thích rằng giao tiếp hai chiều phù hợp hơn với tính chất sự kiện của DOM trình duyệt. Tài liệu này đang ở trên lộ trình Khuyến nghị của W3C nhưng vẫn là một Bản dự thảo làm việc. Do đó, các thiết kế sản xuất nên coi tài liệu mới nhất và các triển khai hiện tại như những bề mặt di chuyển và xác minh mỗi mô-đun cần thiết.

Lệnh, Kết quả, Lỗi và Sự kiện chia sẻ một WebSocket

Một thông điệp BiDi xác định một phương thức như một lệnh mô-đun và mang theo các tham số. Các lệnh có các định danh do khách hàng điều khiển để các kết quả hoặc lỗi có thể được khớp ngay cả khi nhiều hoạt động diễn ra đồng thời và hoàn thành không theo thứ tự. Các sự kiện mang một tên phương thức và dữ liệu nhưng không phải là phản hồi cho một lệnh cụ thể. Khách hàng đăng ký các tên sự kiện, tùy chọn theo ngữ cảnh duyệt hoặc người dùng, và có thể hủy đăng ký khi tín hiệu không còn cần thiết.

Tài liệu tham khảo MDN WebDriver BiDi miêu tả BiDi như một biến thể dựa trên WebSocket, dựa trên sự kiện của WebDriver và cung cấp các trang tham khảo cho các mô-đun, lệnh và sự kiện. Kết nối liên tục thay đổi kiến trúc khách hàng: phân phối thông điệp, thời gian tồn tại đăng ký, thứ tự, đệm, và dọn dường trở thành các mối quan tâm rõ ràng. Khách hàng không nên giả định rằng thứ tự đến của sự kiện đơn thuần chứng minh trạng thái kinh doanh cuối cùng của ứng dụng.

• Mô-đun. Một không gian tên nhóm các lệnh và sự kiện liên quan, chẳng hạn như phiên, trình duyệt, ngữ cảnh duyệt web, mạng, kịch bản, nhật ký, lưu trữ hoặc nhập liệu.
• Lệnh. Một yêu cầu bất đồng bộ từ khách hàng mang theo một định danh, phương thức và tham số và sau đó nhận được một kết quả hoặc lỗi khớp.
• Sự kiện. Một thông báo xuất phát từ trình duyệt báo cáo hoạt động đã đăng ký mà không bị ràng buộc vào một yêu cầu khách hàng mới.
• Đăng ký. Khách hàng chọn các tên sự kiện và các ngữ cảnh tùy chọn mà nó muốn đầu cuối từ xa phát sinh.
• Ngữ cảnh và lĩnh vực. Các ngữ cảnh duyệt web đại diện cho các tab hoặc khung, trong khi các lĩnh vực kịch bản đại diện cho các môi trường thực thi bên trong những ngữ cảnh đó.

BiDi có thể bắt đầu thông qua một phiên WebDriver hoặc một đường dẫn chỉ BiDi

Một khách hàng có thể yêu cầu khả năng URL WebSocket trong khi tạo một phiên WebDriver. Một đầu từ xa hỗ trợ trả về một URL kết nối và đánh dấu phiên đó là đã cho phép BiDi. Tài liệu cũng cho phép các triển khai tiết lộ các phiên chỉ BiDi thông qua một URL kết nối bên ngoài. Khi đã kết nối, khách hàng có thể quản lý các đăng ký và phát hành lệnh mô-đun. Đường dẫn khởi động thực tế phụ thuộc vào trình duyệt, trình điều khiển, thư viện khách hàng và dịch vụ từ xa.

hướng dẫn hỗ trợ chính thức của Puppeteer WebDriver BiDi giải thích cách Puppeteer sử dụng WebDriver BiDi cho Chrome và Firefox và lưu ý rằng các tính năng không được hỗ trợ gây ra lỗi rõ ràng. Đây là một ví dụ thực tiễn về việc triển khai tiến bộ: một khách hàng có thể tiết lộ một đường dẫn BiDi hữu ích trong khi vẫn giữ lại CDP cho các tính năng Chrome mà BiDi chưa bao phủ được trong ngăn xếp đó. Kiến trúc nên cho phép kiểm tra khả năng hoặc sử dụng giải pháp thay thế có phạm vi mà không trình bày sự hỗ trợ một phần như là đối số về toàn bộ tính tương thích của giao thức.

WebDriver cổ điển, WebDriver BiDi, và CDP phục vụ các mục tiêu khác nhau

Các giao thức chồng chéo, nhưng cách vận chuyển, mô hình sự kiện, phạm vi tiêu chuẩn hóa và tính trưởng thành của triển khai khác nhau.

Nơi mà Sự kiện Hai chiều Thay đổi Thiết kế Tự động hóa

BiDi có giá trị khi hoạt động bắt nguồn từ trình duyệt là một phần của mô hình kết quả hoặc đồng bộ hóa thay vì dữ liệu gỡ lỗi tình cờ.

Đặc tả và Triển khai vẫn đang phát triển

Một Bản nháp Công việc W3C có thể thay đổi, và các triển khai thường sẽ có một mô-đun hoặc lệnh tại một thời điểm. Hỗ trợ trình duyệt, hỗ trợ driver, các ràng buộc của khách hàng và dịch vụ từ xa có thể di chuyển trên các lịch trình khác nhau. Một yêu cầu tương thích công khai do đó cần có ngày và danh sách tính năng trong ghi chú kỹ thuật nội bộ, mặc dù một wiki vĩnh cửu nên tránh các bảng phiên bản giòn.

Tham chiếu MDN cho các mô-đun WebDriver BiDi liệt kê các mô-đun BiDi và không gian tên lệnh và sự kiện của chúng. Danh sách này hữu ích cho việc phát hiện nhưng không phải là bằng chứng rằng mọi trình duyệt đều triển khai mọi mục. Tham khảo kết quả triển khai, thông tin phát hành trình duyệt, và bảng hỗ trợ của thư viện khách hàng, sau đó thực hiện một bài kiểm tra khói tập trung vào sự tuân thủ trong môi trường sản xuất.

Danh sách kiểm tra chấp nhận WebDriver BiDi

Chấp nhận BiDi theo khả năng cần thiết thay vì theo nhãn giao thức. Bài kiểm tra nên chứng minh được vận chuyển, lệnh, sự kiện, ngữ cảnh và hành vi dọn dẹp từ đầu đến cuối.

1. Tên các mô-đun cần thiết. Liệt kê phiên, trình duyệt, ngữ cảnh duyệt web, mạng, kịch bản, nhật ký, lưu trữ, đầu vào hoặc các lệnh và sự kiện khác mà quy trình làm việc cần.
2. Xác nhận đường dẫn khởi động. Xác minh xem khách hàng có yêu cầu webSocketUrl thông qua một phiên cổ điển, kết nối đến một điểm cuối chỉ BiDi, hoặc để một khung quản lý việc thương thảo.
3. Kiểm tra các đăng ký. Đăng ký và hủy đăng ký các sự kiện mong muốn, xác định phạm vi cho các ngữ cảnh liên quan, và xác nhận rằng các phiên không liên quan không rò rỉ sự kiện vào trình xử lý.
4. Xử lý độ đồng thời. Khớp kết quả với các định danh lệnh, cho phép hoàn thành không theo thứ tự và xác định cách phân phối thông điệp hành động khi các sự kiện đến trong khi có các lệnh đang chạy lâu dài.
5. Mô hình vòng đời ngữ cảnh. Theo dõi thẻ, khung, ngữ cảnh người dùng và lĩnh vực kịch bản một cách rõ ràng để các sự kiện và tham chiếu từ xa không được áp dụng sau khi ngữ cảnh của chúng bị hủy bỏ.
6. Khối lượng sự kiện ràng buộc. Chọn chỉ các loại sự kiện cần thiết, lọc sớm, xác định việc đệm và áp lực phản hồi, và tránh giữ lại các tải trọng chứa dữ liệu cá nhân hoặc bí mật không liên quan.
7. Bảo tồn một đường dẫn được hỗ trợ. Giữ WebDriver cổ điển hoặc các bộ biến đổi CDP cho các tính năng chịu tải đang thiếu từ trình duyệt và khách hàng đã chọn, với các bài kiểm tra khiến cho ranh giới trở nên rõ ràng.
8. Xác thực lại các nâng cấp. Chạy bài kiểm tra khói giao thức khi trình duyệt, driver, thư viện khách hàng, dịch vụ từ xa hoặc triển khai đặc tả thay đổi.

WebDriver BiDi và Hạ tầng Trình duyệt Được Quản lý

Một dịch vụ trình duyệt được quản lý có thể đóng vai trò là đầu xa trong khi một ứng dụng khách chạy ở nơi khác, nhưng giao thức điểm cuối và các mô-đun được hỗ trợ phải được xác minh một cách rõ ràng. Scrapeless Scraping Browser cung cấp hạ tầng trình duyệt từ xa cho các khách hàng tự động hóa được hỗ trợ; nó không nên được mô tả là một điểm cuối BiDi trừ khi tài liệu hiện tại và một bài kiểm tra tương thích trực tiếp xác nhận rằng con đường đó.

Sử dụng tài liệu dịch vụ để xác định khách hàng và mô hình kết nối được hỗ trợ, sau đó kiểm tra mọi sự kiện và lệnh cần thiết trước khi chấp nhận. Xem xét hiện tại Tổng quan sản phẩm Scrapeless Scraping Browser, Tài liệu khởi đầu Scrapeless Scraping Browser, và Giá cả Scrapeless trước khi chọn một mô hình hoạt động.

Kết luận: BiDi Đưa Sự kiện Trình duyệt Vào Một Con Đường Chuẩn

WebDriver BiDi thêm một kết nối sự kiện liên tục, hai chiều, dựa trên sự kiện vào gia đình WebDriver. Các mô-đun tổ chức các lệnh và sự kiện, các đăng ký kiểm soát những gì trình duyệt phát ra, và các định danh lệnh không đồng bộ cho phép vài thao tác ở trạng thái chờ.

Hãy áp dụng nó một cách cẩn thận. Đặc tả vẫn là một Dự thảo làm việc, hỗ trợ được thực hiện theo từng tính năng, và CDP hoặc WebDriver cổ điển có thể vẫn mang theo các thao tác yêu cầu.