¿Qué es WebDriver BiDi? Automatización bidireccional del navegador

Scraping sin scrapear proporciona infraestructura de navegador gestionada para clientes de automatización cuyos requisitos de protocolo y evento han sido verificados contra el servicio.

WebDriver BiDi añade un canal de eventos en vivo al control del navegador

El WebDriver clásico se basa en solicitudes discretas de clientes y respuestas remotas. Ese modelo maneja la navegación, la entrada, los elementos, las ventanas, las cookies, las capturas de pantalla y los scripts bien, pero el navegador moderno es impulsado por eventos. Las solicitudes de red comienzan y terminan, aparecen registros, los contextos de navegación se abren o cierran, aparecen diálogos, comienzan las descargas y los scripts se ejecutan independientemente del siguiente comando del cliente. WebDriver BiDi crea una conexión bidireccional persistente para que el cliente pueda suscribirse a esos cambios y recibirlos a medida que ocurren.

Especificación WebDriver BiDi del W3C define WebDriver BiDi como un mecanismo para el control remoto de agentes de usuario y explica que la comunicación bidireccional se ajusta mejor a la naturaleza de eventos del DOM del navegador. El documento está en la pista de Recomendación del W3C, pero sigue siendo un borrador de trabajo. Por lo tanto, los diseños de producción deben tratar la última especificación y las implementaciones actuales como superficies en movimiento y verificar cada módulo requerido.

Comandos, Resultados, Errores y Eventos Comparten Un WebSocket

Un mensaje BiDi identifica un método como un comando de módulo y lleva parámetros. Los comandos tienen identificadores controlados por el cliente para que los resultados o errores puedan coincidir incluso cuando varias operaciones se ejecutan concurrentemente y terminan fuera de orden. Los eventos llevan un nombre de método y datos pero no son respuestas a un comando específico. El cliente se suscribe a nombres de eventos, opcionalmente limitados a contextos de navegación o usuario, y puede darse de baja cuando la señal ya no sea necesaria.

Referencia WebDriver BiDi de MDN describe BiDi como una variante de WebDriver basada en WebSocket y impulsada por eventos, y proporciona páginas de referencia para módulos, comandos y eventos. La conexión persistente cambia la arquitectura del cliente: el despacho de mensajes, la duración de suscripción, el orden, el almacenamiento en búfer y la limpieza se convierten en preocupaciones explícitas. Un cliente no debe asumir que el orden de llegada de los eventos por sí solo prueba el estado final del negocio de la aplicación.

• Módulo. Un espacio de nombres agrupa comandos y eventos relacionados, como sesión, navegador, contexto de navegación, red, script, registro, almacenamiento o entrada.
• Comando. Una solicitud asíncrona del cliente lleva un identificador, método y parámetros y luego recibe un resultado o error coincidente.
• Evento. Una notificación originada en el navegador informa sobre la actividad suscrita sin estar atada a una nueva solicitud del cliente.
• Suscripción. El cliente selecciona los nombres de los eventos y los contextos opcionales que desea que el extremo remoto emita.
• Contexto y reino. Los contextos de navegación representan pestañas o marcos, mientras que los reinos de script representan entornos de ejecución dentro de esos contextos.

BiDi puede iniciar a través de una sesión WebDriver o una ruta solo BiDi

Un cliente puede solicitar la capacidad de URL de WebSocket al crear una sesión WebDriver. Un extremo remoto que lo soporte devuelve una URL de conexión y marca la sesión como habilitada para BiDi. La especificación también permite que las implementaciones expongan sesiones solo de BiDi a través de una URL de conexión fuera de banda. Una vez conectado, el cliente puede gestionar suscripciones y emitir comandos de módulos. La ruta real de inicio depende del navegador, controlador, biblioteca de cliente y servicio remoto.

guía oficial de soporte de Puppeteer WebDriver BiDi explica cómo Puppeteer utiliza WebDriver BiDi para Chrome y Firefox y nota que las características no soportadas generan un error explícito. Este es un ejemplo práctico de implementación progresiva: un cliente puede exponer una ruta BiDi útil mientras retiene CDP para las características de Chrome que BiDi aún no cubre en esa pila. La arquitectura debe permitir verificaciones de capacidades o retrocesos limitados sin presentar soporte parcial como paridad total del protocolo.

WebDriver Clásico, WebDriver BiDi y CDP cumplen diferentes objetivos

Los protocolos se superponen, pero su transporte, modelo de eventos, alcance de estandarización y madurez de implementación difieren.

Donde los eventos bidireccionales cambian el diseño de la automatización

BiDi es valioso cuando la actividad originada en el navegador es parte del resultado o modelo de sincronización en lugar de datos de depuración incidentales.

La especificación y las implementaciones aún están evolucionando

Un borrador de trabajo de W3C puede cambiar, y las implementaciones comúnmente se integran un módulo o comando a la vez. El soporte del navegador, soporte del controlador, vinculaciones del cliente y servicios remotos pueden moverse en diferentes horarios. Por lo tanto, una declaración pública de compatibilidad necesita una fecha y una lista de características en notas internas de ingeniería, aunque una wiki siempre verde debería evitar tablas de versiones frágiles. Prueba la suscripción exacta, comando, parámetro y forma de resultado de la que depende la aplicación.

Referencia de MDN para los módulos WebDriver BiDi enumera módulos BiDi y sus espacios de nombres de comandos y eventos. La lista es útil para el descubrimiento, pero no es prueba de que cada navegador implemente cada entrada. Consulta los resultados de implementación, información de lanzamiento del navegador y la tabla de soporte de la biblioteca cliente, luego realiza una prueba de humo enfocada en la conformidad en el entorno de producción.

Una lista de verificación de adopción de WebDriver BiDi

Adopta BiDi por capacidad requerida en lugar de por etiqueta de protocolo. La prueba debe probar el transporte, comando, evento, contexto y comportamiento de limpieza de extremo a extremo.

1. Nombra los módulos requeridos. Lista la sesión exacta, navegador, contextoDeNavegación, red, script, registro, almacenamiento, entrada u otros comandos y eventos que necesita el flujo de trabajo.
2. Confirma la ruta de inicio. Verifica si el cliente solicita webSocketUrl a través de una sesión clásica, se conecta a un punto final solo BiDi o deja que un marco gestione la negociación.
3. Prueba suscripciones. Suscríbete y cancela la suscripción a los eventos deseados, delimítalos a contextos relevantes y confirma que sesiones no relacionadas no filtren eventos en el controlador.
4. Maneja la concurrencia. Empareja resultados con identificadores de comando, permite la finalización fuera de orden y define cómo se comporta el despacho de mensajes cuando los eventos llegan durante comandos de larga duración.
5. Modelo de vida útil del contexto. Rastrea pestañas, marcos, contextos de usuario y reinos de scripts explícitamente para que los eventos y referencias remotas no se apliquen después de que su contexto sea destruido.
6. Volumen de eventos vinculados. Selecciona solo tipos de eventos necesarios, filtra temprano, define almacenamiento en búfer y presión de retorno, y evita retener cargas útiles que contengan datos personales o secretos no relacionados.
7. Preserva un camino soportado. Mantén los adaptadores WebDriver clásicos o CDP para características de carga que falten en el navegador y cliente seleccionados, con pruebas que hagan visible el límite.
8. Revalida actualizaciones. Ejecuta la prueba de humo del protocolo cuando el navegador, controlador, biblioteca cliente, servicio remoto o implementación de especificación cambien.

Infraestructura de navegador gestionada y BiDi WebDriver

Un servicio de navegador gestionado puede alojar el extremo remoto mientras una aplicación cliente se ejecute en otro lugar, pero el protocolo del punto final y los módulos admitidos deben ser verificados explícitamente. Scrapeless Scraping Browser proporciona infraestructura de navegador remoto para clientes de automatización soportados; no debería describirse como un punto final BiDi a menos que la documentación actual y una prueba de compatibilidad en vivo confirmen ese camino.

Usa la documentación del servicio para identificar el cliente soportado y el modelo de conexión, luego prueba cada evento y comando requerido antes de la adopción. Revisa el actual Resumen del producto Scrapeless Scraping Browser, Documentación de inicio de Scrapeless Scraping Browser, y precios de Scrapeless antes de elegir un modelo operativo.

Conclusión: BiDi lleva eventos de navegador a un camino estándar

WebDriver BiDi añade una conexión persistente, bidireccional y orientada a eventos a la familia WebDriver. Los módulos organizan comandos y eventos, las suscripciones controlan lo que emite el navegador y los identificadores de comandos asíncronos permiten que varias operaciones estén en vuelo. El modelo es una mejor coincidencia para la consola, la red, el contexto y la actividad del script que el sondeo clásico por sí solo.

Adóptalo con cuidado. La especificación sigue siendo un borrador de trabajo, el soporte es función por función, y CDP o el WebDriver clásico pueden seguir llevando operaciones requeridas. Un pequeño conjunto de compatibilidad debería definir el verdadero contrato entre el navegador, el controlador, el cliente y el servicio remoto.