Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow using remote Chrome with puppeteer #1002

Open
mhavelant opened this issue Mar 7, 2019 · 9 comments
Open

Allow using remote Chrome with puppeteer #1002

mhavelant opened this issue Mar 7, 2019 · 9 comments

Comments

@mhavelant
Copy link

Puppeteer allows connecting to chrome via a web socket or URL.

See: Puppeteer docs

This would disallow using args (they'd have to be added on the browser-side), though.

Proposal:
Add a remoteOptions key to engineOptions (or maybe a separate remote: bool flag, too?); when this is filled, use await puppeteer.connect() instead of puppeteer.launch().

Use cases:

  • It would be beneficial mainly for dockerized environments, as it would be more in-line with the docker way (one process per container).
@garris
Copy link
Owner

garris commented Mar 7, 2019

3 things...

  1. thank you for this post. You are awesome for putting in this effort

  2. there is already an internal parameter you can use to detect or set remote mode. Search for the switch case that parses for "moby" -- it's around there.

  3. what are potential regressions for existing users? How should this be rilled out? There is currently a request to add a dockerArgs to the config. Should this be part of the same release?

@mhavelant
Copy link
Author

  1. This is a great project, even if I don't contribute code I hope I can add value with these feature ideas. :)

  2. The --moby/--docker arg seems to create a backstop container and run the tests in that. In contrast, my proposal is only about where chrome runs (and only for puppeteer, although chromy might also support such a thing, I didn't check), be it docker or some remote server. They can be used together and would make the --moby (and regular runs) less resource intensive (given there's a remote chrome instance which is set up to accept connections).

  3. I don't really see any potential regressions. According to the docs, connect()˙ returns the same Browser instance as launch(), everything else should be handled by puppeteer internally, so the only 3 things that need to be changed (pseudocode alert):

  • Add a new function e.g getBrowser(options) that should be something like if (isRemote) { return await puppeteer.connect(...)) } else { return await puppeteer.launch(...); } and replace current p.launch() usages with it
  • Add a new function e.g releaseBrowser(options, browser) that could be something like if (isRemote) { return await browser.disconnect(...); } else { return await browser.close() } and replace current browser.close() usages with it
  • Add new parameters (which, when omitted, default to the current functionality)

Disclaimer: this is just headcanon, an actual implementation might be more difficult. :)

@mhavelant
Copy link
Author

Thinking of it, another use case would be scalability (e.g in CI/CD when having lots of tests). Backstop on its own doesn't really use a lot of resources, the main hogs are the browsers. Having the ability to move the resource-intensive stuff to a different machine should help with this.

@garris
Copy link
Owner

garris commented Mar 8, 2019

Wow. That just made my head explode. 🤯

  1. The --moby/--docker arg seems to create a backstop container and run the tests in that. In contrast, my proposal is only about where chrome runs (and only for puppeteer, although chromy might also support such a thing, I didn't check), be it docker or some remote server. They can be used together and would make the --moby (and regular runs) less resource intensive (given there's a remote chrome instance which is set up to accept connections).

@garris
Copy link
Owner

garris commented Mar 8, 2019

Very cool idea. Would be fantastic if someone wants to build it.

@hamtaai
Copy link

hamtaai commented Mar 9, 2019

Created a PR for it (note, I'm mhavelant, this is only my personal account, the other one is my work account). :)

@garris
Copy link
Owner

garris commented Mar 10, 2019

This is cool -- thank you! I have some changes on the npm canary branch that need to be released. I will try to get those out next week, then we can merge these and put it out on the canary branch. More later. Cheers!

@jfussion
Copy link

@garris is this still going to be merged?

@danielepolencic
Copy link

I'm interested in this as well.
I'd like to leverage a service such as browserless.io instead of maintaining my own puppeteer locally.
Happy to help with rebasing/amending the PR if it can be merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants