3 ms·

Yeah, it may just be me, but I was looking into WebDriver crates yesterday to try and control browser engines, and there are non-async ones, but async ones seem

by berkut 5y ago

Yeah, it may just be me, but I was looking into WebDriver crates yesterday to try and control browser engines, and there are non-async ones, but async ones seem more common (at least in terms of blog posts talking about them). The examples they give to use the API using async, I really don't understand, and I can only assume I'm missing something: the example steps of going to a URL, finding a resultant element, entering text, then clicking the search button, then finding another element and then capturing a .png snapshot image for the result are in my mind all sequential, and depend on the previous step: I really struggle to understand how async helps in this case (at least the basic one), as I don't see how any of those steps can be parallelised.

Arnavion 5y ago
The fact that they're async doesn't mean you're expected to be able to parallelize the calls, just that you can do something else while waiting for a response if you want. They involve IPC to another process which can take its own arbitrary amount of time to return a response. There's no reason to block your program during that period. I don't know anything about webdriver's API specifically, but as a general example, "do something else while waiting for a response" can include "stop waiting for a response after a timeout expires". Maybe you want to set a timeout on the "fetch a URL" function call. You can't do that with a synchronous function unless the function internally supports a timeout. With an asynchronous function you can just race it with a timeout future, and if the timeout future completes first you can stop waiting for the fetch future and fail your test.
jgraham 5y ago
(I work on WebDriver standard / implementation) Classic WebDriver, when used to control a single browser is indeed a synchronous API. So for example the server-side WebDriver implementation used in geckodriver is fully synchonous; it accepts a HTTP request, and does a bunch of blocking work to execute that command in Firefox. But there are a couple of reasons you might want an async client, even though the browser side is synchronous: * You might want to drive multiple browsers at the same time. For example when running multiple tests in parallel you would have multiple concurrent requests going to different browser instances. Obviously you could implement that as multiple threads/processes/etc. but if async has the ergonomics you're looking for it is certainly a viable option. * Modern extensions to WebDriver don't follow the command/response model. Many clients have additional functionality that's not implemented on top of WebDriver, but using browsers' built in debugging protocol. Even Selenium these days uses the Chrome Debug Protocol for some features (e.g. access to logs). Those protocols are event based and so not suitable for a fully blocking API. Of course one could still design something that doesn't require async for those use cases, but I think it's generally believed that async offers the best APIs in languages that support it.

by berkut 5y ago

Arnavion 5y ago

The fact that they're async doesn't mean you're expected to be able to parallelize the calls, just that you can do something else while waiting for a response if you want. They involve IPC to another process which can take its own arbitrary amount of time to return a response. There's no reason to block your program during that period. I don't know anything about webdriver's API specifically, but as a general example, "do something else while waiting for a response" can include "stop waiting for a response after a timeout expires". Maybe you want to set a timeout on the "fetch a URL" function call. You can't do that with a synchronous function unless the function internally supports a timeout. With an asynchronous function you can just race it with a timeout future, and if the timeout future completes first you can stop waiting for the fetch future and fail your test.

jgraham 5y ago

(I work on WebDriver standard / implementation) Classic WebDriver, when used to control a single browser is indeed a synchronous API. So for example the server-side WebDriver implementation used in geckodriver is fully synchonous; it accepts a HTTP request, and does a bunch of blocking work to execute that command in Firefox. But there are a couple of reasons you might want an async client, even though the browser side is synchronous: * You might want to drive multiple browsers at the same time. For example when running multiple tests in parallel you would have multiple concurrent requests going to different browser instances. Obviously you could implement that as multiple threads/processes/etc. but if async has the ergonomics you're looking for it is certainly a viable option. * Modern extensions to WebDriver don't follow the command/response model. Many clients have additional functionality that's not implemented on top of WebDriver, but using browsers' built in debugging protocol. Even Selenium these days uses the Chrome Debug Protocol for some features (e.g. access to logs). Those protocols are event based and so not suitable for a fully blocking API. Of course one could still design something that doesn't require async for those use cases, but I think it's generally believed that async offers the best APIs in languages that support it.