O que é o WebDriver BiDi? Automação Bidirecional do Navegador

O Browser de Scraping Sem Raspagem fornece infraestrutura de navegador gerenciada para clientes de automação cujos requisitos de protocolo e evento foram verificados com o serviço.

WebDriver BiDi adiciona um Canal de Evento Ao Vivo ao Controle do Navegador

O WebDriver clássico é construído em torno de solicitações discretas do cliente e respostas remotas. Esse modelo lida bem com navegação, entrada, elementos, janelas, cookies, capturas de tela e scripts, mas o navegador moderno é orientado a eventos. Solicitações de rede começam e terminam, logs aparecem, contextos de navegação abrem ou fecham, diálogos aparecem, downloads começam e scripts são executados independentemente do próximo comando do cliente. O WebDriver BiDi cria uma conexão bidirecional persistente para que o cliente possa assinar essas mudanças e recebê-las à medida que ocorrem.

Especificação WebDriver BiDi do W3C define o WebDriver BiDi como um mecanismo para controle remoto de agentes de usuário e explica que a comunicação bidirecional combina melhor com a natureza orientada a eventos do DOM do navegador. O documento está na trilha de Recomendação do W3C, mas permanece como um Rascunho de Trabalho. Portanto, projetos de produção devem tratar a especificação mais recente e implementações atuais como superfícies em movimento e verificar cada módulo necessário.

Comandos, Resultados, Erros e Eventos Compartilham Um WebSocket

Uma mensagem BiDi identifica um método, como um comando de módulo, e carrega parâmetros. Comandos têm identificadores controlados pelo cliente, assim resultados ou erros podem ser correspondidos mesmo quando várias operações são executadas simultaneamente e terminam fora de ordem. Eventos carregam um nome de método e dados, mas não são respostas a um comando específico. O cliente assina nomes de eventos, opcionalmente limitados a contextos de navegação ou de usuário, e pode cancelar a assinatura quando o sinal não for mais necessário.

Referência WebDriver BiDi do MDN descreve o BiDi como uma variante do WebDriver baseada em WebSocket e orientada a eventos e fornece páginas de referência para módulos, comandos e eventos. A conexão persistente muda a arquitetura do cliente: despacho de mensagens, duração da assinatura, ordenação, bufferização e limpeza tornam-se preocupações explícitas. Um cliente não deve presumir que a ordem de chegada dos eventos sozinha prova o estado final do negócio da aplicação.

• Módulo. Um namespace agrupa comandos e eventos relacionados, como sessão, navegador, contexto de navegação, rede, script, log, armazenamento ou entrada.
• Comando. Uma solicitação assíncrona do cliente leva um identificador, método e parâmetros e posteriormente recebe um resultado ou erro correspondido.
• Evento. Uma notificação originada no navegador reporta atividade assinada sem estar vinculada a uma nova solicitação do cliente.
• Assinatura. O cliente seleciona os nomes dos eventos e contextos adicionais que deseja que a extremidade remota emita.
• Contexto e reino. Contextos de navegação representam abas ou frames, enquanto reinos de script representam ambientes de execução dentro desses contextos.

O BiDi pode começar através de uma Sessão WebDriver ou um Caminho Somente BiDi

Um cliente pode solicitar a capacidade da URL WebSocket ao criar uma sessão WebDriver. Uma extremidade remota que oferece suporte retorna uma URL de conexão e marca a sessão como habilitada para BiDi. A especificação também permite que implementações exponham sessões somente BiDi através de uma URL de conexão fora da banda. Uma vez conectado, o cliente pode gerenciar assinaturas e emitir comandos de módulo. O caminho real de inicialização depende do navegador, driver, biblioteca do cliente e serviço remoto.

guia oficial de suporte Puppeteer WebDriver BiDi explica como o Puppeteer usa o WebDriver BiDi para Chrome e Firefox e observa que recursos não suportados geram um erro explícito. Este é um exemplo prático de implementação progressiva: um cliente pode expor um caminho BiDi útil enquanto retém o CDP para recursos do Chrome que o BiDi ainda não cobre naquele conjunto. A arquitetura deve permitir verificações de capacidade ou quedas limitadas sem apresentar suporte parcial como paridade de protocolo total.

WebDriver Clássico, WebDriver BiDi e CDP Servem a Objetivos Diferentes

Os protocolos se sobrepõem, mas seu transporte, modelo de eventos, escopo de padronização e maturidade de implementação diferem.

Onde eventos bidirecionais mudam o design da automação

BiDi é valioso quando a atividade originada no navegador é parte do modelo de resultado ou sincronização, em vez de dados de depuração incidentais.

A especificação e as implementações ainda estão evoluindo

Um rascunho de trabalho do W3C pode mudar, e as implementações geralmente implantam um módulo ou comando de cada vez. O suporte do navegador, suporte do driver, vinculações do cliente e serviços remotos podem avançar em cronogramas diferentes. Portanto, uma reivindicação pública de compatibilidade precisa de uma data e uma lista de recursos nas notas internas de engenharia, embora uma wiki perene deva evitar tabelas de versão frágeis. Teste a assinatura, comando, parâmetro e formato de resultado exatos que a aplicação depende.

Referência MDN para módulos WebDriver BiDi lista os módulos BiDi e seus namespaces de comando e evento. A lista é útil para descoberta, mas não é prova de que cada navegador implementa cada entrada. Consulte os resultados de implementação, informações de lançamento do navegador e a tabela de suporte da biblioteca do cliente, e então execute um teste de fumaça focado em conformidade no ambiente de produção.

Uma lista de verificação de adoção do WebDriver BiDi

Adote o BiDi pela capacidade necessária, em vez do rótulo do protocolo. O teste deve provar o transporte, comando, evento, contexto e comportamento de limpeza de ponta a ponta.

1. Nomeie os módulos necessários. Liste a sessão exata, navegador, contexto de navegação, rede, script, log, armazenamento, entrada ou outros comandos e eventos que o fluxo de trabalho precisa.
2. Confirme o caminho de inicialização. Verifique se o cliente solicita webSocketUrl através de uma sessão clássica, conecta-se a um ponto final somente BiDi ou permite que um framework gerencie a negociação.
3. Teste assinaturas. Assine e desinscreva-se dos eventos pretendidos, delimite-os a contextos relevantes e confirme que sessões não relacionadas não vazem eventos para o manipulador.
4. Gerencie concorrência. Combine resultados com identificadores de comando, permita a conclusão fora de ordem e defina como o despacho de mensagens se comporta quando eventos chegam durante comandos de longa duração.
5. Modele o tempo de vida do contexto. Rastreie abas, frames, contextos de usuário e reinos de script explicitamente para que eventos e referências remotas não sejam aplicados após seu contexto ser destruído.
6. Volume de eventos vinculados. Selecione apenas os tipos de eventos necessários, filtre cedo, defina buffer e contrapartida, e evite reter cargas úteis que contenham dados pessoais ou secretos não relacionados.
7. Preserve um caminho suportado. Mantenha adaptadores WebDriver clássicos ou CDP para recursos essenciais ausentes do navegador e cliente selecionados, com testes que tornem o limite visível.
8. Revalide atualizações. Execute o teste de fumaça do protocolo quando o navegador, driver, biblioteca do cliente, serviço remoto ou implementação da especificação muda.

WebDriver BiDi e infraestrutura de navegador gerenciado

Um serviço de navegador gerenciado pode hospedar a extremidade remota enquanto uma aplicação cliente é executada em outro lugar, mas o protocolo do ponto final e os módulos suportados devem ser verificados explicitamente. Scrapeless Scraping Browser fornece infraestrutura de navegador remoto para clientes de automação suportados; não deve ser descrito como um ponto final BiDi, a menos que a documentação atual e um teste de compatibilidade ao vivo confirmem esse caminho.

Use a documentação do serviço para identificar o cliente suportado e o modelo de conexão, e então teste todos os eventos e comandos necessários antes da adoção. Revise o atual Visão geral do produto Scrapeless Scraping Browser, documentação de início rápido do Scrapeless Scraping Browser, e preço do Scrapeless antes de escolher um modelo operacional.

Conclusão: BiDi traz eventos de navegador para um caminho de padrões

WebDriver BiDi adiciona uma conexão persistente, bidirecional e orientada por eventos à família WebDriver. Os módulos organizam comandos e eventos, as assinaturas controlam o que o navegador emite e os identificadores de comando assíncronos permitem que várias operações estejam em andamento. O modelo é uma correspondência melhor para atividades de console, rede, contexto e script do que a sondagem clássica sozinha.

Adote-o com cuidado. A especificação permanece um Rascunho de Trabalho, o suporte é recurso por recurso, e o CDP ou o WebDriver clássico ainda podem exigir operações necessárias. Um pequeno conjunto de compatibilidade deve definir o contrato real entre navegador, driver, cliente e serviço remoto.