3 ms·

I'd recommend moving away from Node... Taking a wild guess: Some of their bank integrations probably require browser automation. If you're doing browser automa

I'd recommend moving away from Node... Taking a wild guess: Some of their bank integrations probably require browser automation. If you're doing browser automation, the best tool for the job is (currently) Puppeteer, which runs on Node. There are other third-party language bindings for the Chrome dev tools protocol, but Puppeteer is developed by Google as a first-class citizen alongside Chrome.

paulddraper 7y ago
I think that overemphasizes Pupeteer itself. It's really just bindings for the dev tools protocol. Half the GitHub issues result in "well the protocol requires X and we can't change that". Pupeteer is popular because it's web automation protocol bindings for a web language, not because it a sophisticated layer or does very much. There are literally dozens of language bindings for the protocol. [1] Some are quite good and widely used, for example chromedp (Go bindings). [2] [1] https://github.com/ChromeDevTools/awesome-chrome-devtools#protocol-driver-libraries https://github.com/ChromeDevTools/awesome-chrome-devtools#pr... [2] https://github.com/chromedp/chromedp https://github.com/chromedp/chromedp
rdsubhas 7y ago
4000 chrome instances? Probably not. Here I am trying to run 4 chrome instances in parallel in CI without crashing.
- stickfigure 7y ago
  Presumably not every integration requires browser automation, so they might not all be going at once. But they have a $25k monthly EC2 bill, so it's not out of the ballpark. FWIW, I reliably have 6 puppeteer/chrome instances (headful, even) going on a single box and it's not even at half capacity.
- rmetzler 7y ago
  Check out the selenoid project. It’s like a selenium grid but dockerized with novnc, etc.