Hey folks! I'm Joel, entrepreveloper behind this browserless.io service, happy to answer questions or chat!
Is it a programming api to chrome? As in:
host:~$ ./browserless-app example.com # will fetch an interact using js/DOM with the web @ url
Is this supposed to be used as a proxy between some random browser, a remote chrome browser and the http response? As in:
<IE/edge/safary script> page-load: ws.connect(ws://mybless-service/); this.html = ws.recv()</script>
Or is it more oriented to have a remote service which you can use to send commands to process and control browsing sessions? login to foobar.org; update this data. fetch something; return data/status too peer.
I'm really lost. A sugestion. I cant check 4 layers of subproject dependencies in orther to have a clear picture of what the thing does. An how it does it. I dont know if this is a node server running standalone (can I autodeploy this service in my server? Is this a saas?), or something you use in the client js. Or something you can access from the client side that internally connects to a websocket. Or even a mix of all this. A clear arquitectural design diagram helps IMO in this things:
- Layer A runs on yours/ours/both linux/$X server using Y framework
- Layer B Is a websocket service (standalone/saas) for clients to consume.
- Layer C is a browser client js API wrapper for the service.
- This is useful for this <full use case and run session of the example>
Dont get me wrong, this is not a hate comment. Is just a personal suggestion to help people not deeply invested in JS/node ecosystem. Maybe its me just being thick this morning and not getting it.
Thanks, it looks very cool anyway.
As of now it's a pool of headless Chrome instances that you can control remotely and run tasks through. Screenshots, PDFs, scraping... whatever you need. The reason that folks use this is because it's _really scary_ to run Chrome alongside your app's infra, so separating it out (much like a DB) is a good idea.
In the near-future we'll offer functions and other REST endpoints for doing common and user-defined tasks. This make it even more contained so your app can keep running happily without babysitting Chrome.
Great question!
I had fun collaborating with you last year on a puppeteer docker thread in GitHub.
I’m super happy browserless is picking up. A bit jealous of your success but still rooting for you!
Containerized Puppeteer is amazing. Hope Google acquires browserless.io some day.
Indeed it looks very useful.
Have you seen any similar behavior in your system? I initially thought I was forgetting to close the browser instance but triple checked my code and it does seem like I'm calling close() everywhere.
- Sometimes Promise returned by page.close() never resolves so it's good to call Promise.race() on that together with a Promise that resolves after some timeout period (30s?)
- Sometimes Chrome process doesn't get killed so we are also manually killing remaining Chrome process after browser.close()