3 ms·
Hi. What is this exactly? Skimming through the site didnt give me a clear detailed explanation. Is it a programming api to chrome? As in: host:~$ ./browserles
by int0x80 8y ago
Hi. What is this exactly? Skimming through the site didnt give me a clear detailed explanation.
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.
- mrskitch 8y agoYeah, definitely a product that you don't realize you need...until you find the issue. 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!
- nojvek 8y agoHi Joel, 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.
- int0x80 8y agoThanks very much for the clarification. Indeed it looks very useful.