GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-07-26) - page 1 of 10
 
___________________________________________________________________
Show HN: Chromeless - Headless Chrome Automation on AWS Lambda
125 points by schickling
https://github.com/graphcool/chromeless
___________________________________________________________________
 
victorhooi - 3 hours ago
So to clarify - this is basically a Node.JS wrapper around Chrome
headless, right? =_)Seems pretty awesome.My use case is to take
screenshots of various pages - the docs don't mention the default
viewport dimensions, btw.
 
  schickling - 3 hours ago
  Yes exactly + this can run (in parallel) on AWS Lambda, so you
  don't need to worry about provisioning & running servers. That's
  actually the part I'm most excited about :)
 
    purvis - 3 hours ago
    It's parallel because AWS Lambda is inherently parallel? Or are
    you referring to within JavaScript?
 
      adieuadieu - 2 hours ago
      Parallel in that you can invoke many Lambda functions at the
      same time and have them run independently of each other
 
        dlisboa - 2 hours ago
        So basically if I had 200 automations I could run them on
        200 lambdas and have them finish by the time the slowest
        one finishes? That pretty awesome, specially for testing.
        For many cases this would also fall under the free tier
        since it not that many requests/usage...it kinda seems too
        good to be true. Am I missing something?
 
          schickling - 2 hours ago
          Nope, welcome to the serverless future! :)
 
          dlisboa - 2 hours ago
          You guys should put up an example on how to convert a
          (small) test suit to use it, like you said you did in
          your top comment. The examples you have are cool but
          don't really help visualize that parallelism gain.
 
          schickling - 2 hours ago
          Sounds like a great idea. Would you mind creating an
          issue here so we can track this?
          https://github.com/graphcool/chromeless/issues
 
          dlisboa - 1 hours ago
          Done.
 
          bald - 1 hours ago
          > For many cases this would also fall under the free tier
          since it not that many requests/usage...it kinda seems
          too good to be true(since I've ran into the same trap a
          couple of weeks ago and ended up with USD 650 of
          unanticipated charges): the free Lambda tier includes* 1M
          requests* 400k GB-seconds--> the GBsec can be a serious
          bottleneck. Imagine you're running each Lambda instance
          with 512MB RAM and each instance takes 2 mins to complete
          your test. This means that one Lambda instance is ~61.5
          GBsec, meaning you can execute ~6,500 of these instances
          per month to remain in the free tier.Depending on how
          extensive your tests are/how often you run them, you
          might run out of free GBsec well before you'd run out of
          the requests quota.
 
          adieuadieu - 2 hours ago
          Yep. That's one of the main reasons why we're so excited
          about this project!
 
          MoOmer - 54 minutes ago
          Haven't had time to read the source yet, how are the
          lambda headless chrome reliability issues dealt with? Is
          it a different chrome build than serverless-chrome?
 
          adieuadieu - 40 minutes ago
          For now, we're using the workaround proposed here:
          https://github.com/adieuadieu/serverless-
          chrome/issues/41#is...The Chromeless Proxy service uses
          the @serverless-chrome/lambda package as is. Same build.
 
  roughcoder - 3 hours ago
  agreed no default is mentioned but you can declare with `await
  chromeless.viewport(1024, 800)`
 
megamindbrian - 1 hours ago
Cool.  Now can you use it with webdriver functions instead of re-
inventing the API?
 
languagehacker - 2 hours ago
We've been using chrome-remote-interface for test automation in a
project that makes heavy use of Lambda for a distributed event
processing infrastructure. I'm looking forward to seeing whether we
can implement this for running our test automation suite!
 
  schickling - 2 hours ago
  Would love to hear how that goes. Please reach out if you have
  any problems or questions. The easiest way is to ping me on
  Slack: https://slack.graph.cool
 
iokevins - 3 hours ago
One minor housekeeping comment:The first two examples seem to
return 404, for me:https://github.com/graphcool/chromeless#examples
 
  schickling - 3 hours ago
  Thanks a lot. This is fixed now!
 
yamafaktory - 3 hours ago
Looks super promising, the API is really neat and running the tests
in parallel is a big plus! Awesome work!
 
Vuneu - 41 minutes ago
This is pretty nifty! I've been keeping an eye on Phantomium for a
while, I wonder what's come out of it.
 
  kensoh - 7 minutes ago
  Looks like Google releasing headless Chrome is really shaking up
  the test automation domain. This is a really cool project :) The
  other day I saw another interesting and refreshing implementation
  using GraphQL - https://github.com/joelgriffith/navalia (not
  affiliated with the project, just got to know from a PhantomJS
  issue).
 
afandian - 1 hours ago
I've got the impression that lots of sites block AWS IP addresses.
I wonder if this would hamper the practical use of this on
Lambda.I'm doing something similar, and this concern was one
motivation for running in our datacentre vs EC2.Does anyone have
concrete info on rates of bots blocked from AWS IPs?
 
  extra88 - 19 minutes ago
  I assume the number one use of this would be test automation for
  one's own sites so blocking would not be an issue.What are sites'
  motivations for blocking AWS IPs? I bet there are some reasons I
  would agree with even though the somewhat crude method of
  blocking ip range would have some unintended consequences (e.g.
  blocking people running a personal VPN).
 
biscarch - 2 hours ago
I've been super excited about Chrome headless but haven't had a
chance to dig into using it yet. The api here looks amazing for
getting started without getting lost in the weeds. It'd be fairly
trivial to hook this up to a Slackbot and to get on-demand
screenshots of various pages on my websites, etc.
 
yeldarb - 2 hours ago
I've been using serverless-chrome for the past few weeks and this
looks like a big improvement in
usability!https://github.com/adieuadieu/serverless-chrome
 
  schickling - 2 hours ago
  Chromeless is actually built on top serverless-chrome and was
  developed together with the author of serverless-chrome :)
 
    adieuadieu - 2 hours ago
    ;-)
 
      kensoh - 41 minutes ago
      Really cool collaboration and project! :)
 
schickling - 3 hours ago
I'm really excited to finally open-source Chromeless. We've used
NightmareJS and similar tools before to run integration tests but
these basically added ~20min to each build. With Chromeless we were
able to reduce this time to under a minute!Here is btw a demo
playground to try it out: https://chromeless.netlify.com/Let me
know if you have any questions :)
 
colordrops - 1 hours ago
Can any headless browser solution be considered complete without
GPU support?  A large percentage of sites use GPU enabled and
accelerated features and without GPU support, headless options are
worthless to many applications.
 
shortj - 3 hours ago
This would have been awesome to have back when I was heavy in to
the UI test automation game. Our best option at that point was a
spot instance EC2 fleet and analyzing commits to determine which
tests would be the most valuable to run. It's awesome being able to
easily run hundreds or thousands of tests in parallel, completely
segmented, and pay only on demand. A fantastic use of AWS Lambda!
It suddenly becomes reasonable to do full integration tests on
every merge request, or even commit, and get feedback to the
developer in seconds.
 
  toomuchtodo - 3 hours ago
  Do the math. If you're suggesting running all the tests,
  drastically increasing your compute volume, it's probably cheaper
  to use a dedicated instance running at max CPU utilization.
 
    shortj - 2 hours ago
    It absolutely depends on how burst driven your utilization
    pattern is, but don't forget the cost to actually manage the
    test cluster, and the engineering cycles that go into
    optimizing and sharding those tests across the cluster.
 
      toomuchtodo - 2 hours ago
      For sure, lots of considerations to take into account. If
      you're already running your own CI pipeline though, tests on
      top of it are trivial (in my experience running a Jenkins CI
      pipeline for a python monolith). Tweak your test runner,
      upsize the EC2 instance, and go grab a mojito.
 
    schickling - 3 hours ago
    It's of course based on what's more important for you: Running
    tests non-stop and perfectly utilizing a compute instance vs
    having the tests executed when you need the results as soon as
    possible. I might argue that in most cases the latter is what
    you'd actually want. Especially given that you're getting
    billed on a millisecond basis.
 
      toomuchtodo - 2 hours ago
      All depends on your test volume and your cost sensitivity.
      Bare cores are cheaper than functions, that's all.
 
      sorenbs - 2 hours ago
      I would love to have something like this for my scala API
      tests. We have 3k tests running on 10 ec2 instances and the
      entire test-suite takes 10 minutes. If some infrastructure
      would allow me to pay a little more and run all tests in
      parallel, that would be a game changer for our team.
 
  schickling - 3 hours ago
  This sounds very familiar. I'm amazed every time to see what
  serverless infrastructure can be used for!
 
titel - 1 hours ago
@schickling - When will the PDF support arrive?
https://github.com/graphcool/chromeless/blob/master/docs/api...
 
  pkilgore - 1 hours ago
  Also interested, this would be excellent fit for a use case I
  have archiving certain important government websites.Btw, does
  the .viewport() option not work in the demo?  I'm seeing a
  `TypeError: Failed to fetch` when I set one.
 
jotto - 3 hours ago
(Shameless promoting): for an API version of the prerendering
functionality, with no warm-up latency, we're running a large
cluster of Chrome headless instances here:
https://www.prerender.cloud/
 
  schickling - 3 hours ago
  Sounds like a great service and very useful for frontend
  developers.We've built something similar internally and will
  shortly migrate it to Chromeless. We basically use it to pre-
  render our websites and docs: https://github.com/graphcool/prep
 
cjr - 20 minutes ago
This looks great! As the developer of an automated screenshot
solution (https://urlbox.io), one of the major pain points when
taking screenshots is font-rendering. I wonder how you could
install/configure fonts on lambda?
 
polskibus - 3 hours ago
Can I use this somehow in a container? Farm out headless chrome +
selenium on a local data center? I would be grateful for any hints.
 
  schickling - 3 hours ago
  We haven't done so yet, but it shouldn't be a problem at all to
  set up Chromeless in a container environment. Would you mind
  creating an issue here to discuss this further?
  https://github.com/graphcool/chromeless/issues/new
 
[deleted]
 
coredog64 - 2 hours ago
The last time I tried headless Chrome, file downloads were a PITA.
Has anyone tried downloads with Chromeless?
 
  adieuadieu - 2 hours ago
  Other than taking a screenshot and evaluating JS code in the
  context of Chrome and returning JSON, we haven't yet implemented
  any file-download features. But it might be possible for us to
  implement something. Would you mind creating an issue here
  describing your use case so we can discuss it further?
  https://github.com/graphcool/chromeless/issues/new
 
    kensoh - 38 minutes ago
    By design, headless Chrome disables file downloads. This is
    being tracked at this issue to offer a way to enable that, and
    the issue seems to be moving along =) https://bugs.chromium.org
    /p/chromium/issues/detail?id=696481EDIT - above is assuming
    downloading a file by simulating a click event to perform the
    download. there may be other workarounds by script injection
    etc to use XMLHttpRequest() for downloading a resource
    directly.