Earlier quoted context omitted.
Playwright is definitely better IMO. Cypress is overengineered.
I wouldn’t say cypress is over engineered. Just a byproduct of its time.
What do you mean?
Playwright: Automate Chromium, WebKit and Firefox
91–100 of 149 posts
Re: Playwright: Automate Chromium, WebKit and Firefox
#92Earlier quoted context omitted.
Edge is chromium though.
Microsoft's web products run on more than Edge.
They try very hard to stop you trying, though; Microsoft Teams has removed the “continue without the Teams app” button entirely on Firefox, even though I'm fairly sure it still works fine in Firefox.
Re: Playwright: Automate Chromium, WebKit and Firefox
#93Earlier quoted context omitted.
Any chance the entire thing can be offloaded to a task queue (Celery/etc)? This would decouple the HTTP request processing from the actual ML task. The memory errors you're seeing could suggest that you may not actually be able to run multiple instances of the model, and even if you could it may not actually give you more performance than processing sequentially. Seems like ultimately your current design can't gracef…
Yeah this is the way. @headlessvictim2 search for "Asynchronous Request-Reply pattern" if you want more information about this kind of architecture. You will remove any bottleneck from the API server and can easily scale out from the task queue.
Thanks for the suggestion.
How would this work with GPU-bound machine learning models?
The model processing takes > 30 seconds and would still represent the bottleneck?
Re: Playwright: Automate Chromium, WebKit and Firefox
#94Playwright is a great tool. I was able to create a proof-of-concept stock screening tool using automation & screenshots of HTML elements to help me get swing trading ideas each morning/night when the market closed. It's a .NET Core console app using a CLI library called spectre.console based on rich(python) and playwright as the workhorse.
There's so much potential to use playwright in CI/CD with GitHub Actions cron jobs. Really enjoying it so far.
Re: Playwright: Automate Chromium, WebKit and Firefox
#95What do people thing of playwright vs cypress? I've been considering using playwright instead as it supports more browsers and I feel like it's easier to do production monitoring (by putting it in a aws lambda or using checkly) - Cypress: https://www.cypress.io - Playwright aws lambda: https://github.com/PauloGoncalvesBH/running-playwright-on-aw... - Checkly: https://www.checklyhq.com
My main issue with Cypress was the fact that it required a shift in mental model, i.e. queuing commands rather than executing them, thenables that aren't actually promises, running as client side JS as opposed to in a controller script. There were a ton of sharp edges and required a lot of education to adopt.
Meanwhile Playwright's API is just promises. Everybody knows how to compose promises.
The Cypress approach does in theory completely eliminate latency-induced flakiness, but in my experience, Playwright/Puppeteer's usage of bi-directional real-time protocols to communicate with the browser makes latency low enough that latency-induced flakiness is no longer a practical concern, especially when paired with the ability to selectively run test logic in client-side JS in the page with 0 latency.
Selenium did suffer from latency-induced flakes all the time due to its slow uni-directional request/response model. I personally believe the Cypress model is an over-correction for Selenium PTSD, and isn't making as good a set of tradeoffs compared to Playwright/Puppeteer.
Re: Playwright: Automate Chromium, WebKit and Firefox
#96Earlier quoted context omitted.
It could be. I watch the FastAPI repos a lot and tones of people do not understand how async python works and put their models with sync code in an async context.
Consider us one. :) We tried removing "async" -- thinking it would force sequential processing -- but it unexpectedly seemed to cause parallel processing of requests, which caused CUDA memory errors. Before removing "async", this is the weird behavior we observed: * Hacker blasts 50-100 requests. * Our ML model processes each request in normal time and sequentially. * But instead of returning individual responses imm…
Python async is co-operative multi-tasking (as opposed to per-emptive)
There is an event loop that goes through all the tasks and runs them.
The issue is the event loop can only move on to the next task when you reach an await. So if you run a lot of code (say an ML model) between awaits no other task can advance during this time.
This is why it is co-operative, it is up to a task to release the event loop, by hitting an await, so other tasks can get work done.
This is fine when you have async libs that often hit awaits at things that are IO related like say db, or http calls.
FastAPI will spawn controllers that are not defined as async functions on a thread pool but it is still a python so GIL and all that.
You should do as the sibling comment says and decouple your http from your ML and feed the ML with something like Celery. This way your server is always there to respond to things (even if just a 429) to hit a cache or whatever else.
Re: Playwright: Automate Chromium, WebKit and Firefox
#97Earlier quoted context omitted.
Selenium is slow and based on webdriver. I think most consider it legacy at this point. Most new projects tend to use Playwright, Cypress, or Puppeteer for E2E tests. All three options are much more performant and reliable.
I've been out of this space for a while, but isn't WebDriver the only cross-browser spec for browser automation? The last I knew, the browser vendors were removing other automation hooks for security reasons and heavily influenced the WebDriver spec.
Well, playwright is cross browser too.
I've only been using/playing with it for a few weeks, but I find it more contemporary and less clunky than selenium. And it's lighter and runs faster. I dislike passing around a driver to tests and the playwright built-in testing (which I think is wrapping the expect library) is pretty nice.
I haven't fully made peace with the selector API in playwright, which uses a lot of experimental css selectors and a custom DSL, but these are minor learning curve issues.
Re: Playwright: Automate Chromium, WebKit and Firefox
#98Earlier quoted context omitted.
We see a strong adoption of Playwright. It’s the default we recommend to users now. We also support Puppeteer, but its development is lagging. Having said that, I would love to support Cypress if I had infinite time and focus. Side note: Selenium is not on the menu, even with its large install base. We are aiming for where the puck is going and it’s going to Playwright. Full disclaimer: I’m CTO at Checkly.
How about Python bindings? Selenium is the only decent option in that space so far, are we wrong?
looks like playwright is bridging this gap too:
Re: Playwright: Automate Chromium, WebKit and Firefox
#99Earlier quoted context omitted.
I've been out of this space for a while, but isn't WebDriver the only cross-browser spec for browser automation? The last I knew, the browser vendors were removing other automation hooks for security reasons and heavily influenced the WebDriver spec.
Well, playwright is cross browser too. I've only been using/playing with it for a few weeks, but I find it more contemporary and less clunky than selenium. And it's lighter and runs faster. I dislike passing around a driver to tests and the playwright built-in testing (which I think is wrapping the expect library) is pretty nice. I haven't fully made peace with the selector API in playwright, which uses a lot of expe…
I'm sorry if not clear, but I was asking about the WebDriver spec [1]. The terminology gets confusing because WebDriver was a tool that then merged with Selenium and Selenium implemented the WebDriver wire protocol. If Playwright isn't using WebDriver, is there a new browser automation API?
Edit: It looks like it's using Chrome's DevTools protocol. I'll have to read up more on that. I thought Google deliberately didn't want that to be used for automation, but I'm probably thinking of something else.
Re: Playwright: Automate Chromium, WebKit and Firefox
#100Earlier quoted context omitted.
Recaptcha v3 doesn’t prompt if it thinks you’re a real user.
This could have major GDPR implications if that's something the parent cares about. ReCaptcha is basically Google spyware that happens to provide captcha services.
it's obvious the parent is trolling.