search

microsoft / playwright

Playwright is a framework for Web Testing and Automation. It allows testing Chromium, Firefox and WebKit with a single API.
https://playwright.dev
Apache License 2.0
65.65k stars 3.57k forks source link

[Feature]: Support for Cloudflare Browser Rendering API #32042

Open dpeek opened 1 month ago

dpeek commented 1 month ago

🚀 Feature Request

Cloudflare offer a simple and very const effective "serverless" chromium in the form of the browser rendering API.

I'd love to use the far superior Playwright API to control this rather than Puppeteer (which they forked to run in a non-node environment).

Would it be technically possible run the Playwright "client" to run in a non-node runtime? I naively took a look myself but it seemed that Playwright is very much tied to Node.

More than happy to put the work in, but was hoping for some feedback on whether this is a fools errand or not :)

Motivation

This would allow us to run our Playwright automations on Cloudflare. As a side benefit you'd basically be able to run the client API in any JS runtime?

yury-s commented 1 month ago

Looks like the browser rendering API exposes DevTools protocol for the headless browser and you should be able to connect to it from Playwright already. So I guess the missing piece is running Playwright itself in the workers.

Playwright does depend on Node.js APIs and there was no design goal to support another runtime. The language ports (Python, .Net and Java) use language specific clients but all of them still share the server part which still runs on Node.js. With that said, it should be possible to implement missing Node APIs to have Playwright run in another environment.

To clarify, you are only talking about Playwright library, not Playwright Test?

dpeek commented 1 month ago

Yes, just the playwright library. Cloudflare does provide a compat layer for many Node APIs, but in my quick investigation it seemed very hard to separate the "server" part (which uses a bunch of Node APIs that they don't support) from the client part (which seems like it should be supportable).

What node dependencies would the client have right now? Is devtools over HTTP/WS? Perhaps an easier way forward would be for me to use one of the other runtime ports of the client as a reference – although it seems wasteful to not use the existing JS client impl as a foundation.

yury-s commented 1 month ago

What node dependencies would the client have right now?

It's 'fs', 'path' for filesystem access, zip and some network stuff (may be stripped off in many scenarios), you can look at the client source and corresponding dependencies from DEPS.list.

Is devtools over HTTP/WS? Perhaps an easier way forward would be for me to use one of the other runtime ports of the client as a reference – although it seems wasteful to not use the existing JS client impl as a foundation.

connectOverCDP is implemented on the server side, so you'll need that one, you cannot just take the client without server. The server dependencies should be mostly limited to fs, process launch API (which you shouldn't need when connecting over CDP), zip and websocket/network. It shouldn't be hard to make it run without filesystem dependencies, if you don't need to load/save any artifacts.

FYI, there was an attempt to run Playwright as an extension: https://github.com/microsoft/playwright/pull/24020, you might find it helpful.