joelgriffith / navalia

A bullet-proof, fast, and reliable headless browser API
https://joelgriffith.github.io/navalia/
GNU General Public License v3.0
957 stars 33 forks source link

Why do we need GraphQL? #39

Open stevenvachon opened 7 years ago

stevenvachon commented 7 years ago

It seems a little heavy (and opinionated) to achieve what Nightmare.js does.

joelgriffith commented 7 years ago

I agree that it's overstepping the boundaries of what a driver should probably do (in this case just parity with Nightmare.js). However I hate having to restrict access to just folks using JavaScript or TypeScript, and the easiest way to get other runtimes onboard is by offering an interface like GraphQL so that anyone can drive the browser.

Does seem like too much for this repo. I might use something like lerna to split up the repositories so it doesn't have multiple objectives.

basarat commented 7 years ago

I agree that it is too much.

However I hate having to restrict access to just folks using JavaScript or TypeScript, and the easiest way to get other runtimes onboard is by offering an interface like GraphQL

A simple TypeScript interface shared by implementations would serve the same purpose.

Does seem like too much for this repo. I might use something like lerna to split up the repositories so it doesn't have multiple objectives.

I would delete it. Mostly because I think it detracts from the great (best) chrome automation you have done here :rose:

dbalatero commented 7 years ago

I'm considering using it to implement a headless Chrome driver for Capybara (ruby/rspec) that doesn't rely on the really sketchy Selenium implementation we have. I'm fine with splitting it though, but just adding this as a datapoint for what I find useful about it.