Your data. Anywhere you go.

New Relic for iOS or Android


Download on the App Store    Android App on Google play


New Relic Insights App for iOS


Download on the App Store


Learn more

Close icon

Feature Idea: Support async/await in synthetics browser scripts

promise
async
synthetics
feature-idea

#1

Most of the entire $browser library is promise driven, for good reason. But it does mean that my code for scripted browsers tends to be a little long and harder to read.

Here’s a simple example of the difference:

$browser.get('https://auth.example.com/')
    .then(() => $browser.waitForAndFindElement($driver.By.css('input[name=email]')).then(e => e.sendKeys(email)))
    .then(() => $browser.waitForAndFindElement($driver.By.css('input[name=password]')).then(e => e.sendKeys(password)))
    .then(() => $browser.waitForAndFindElement($driver.By.css('input[type=submit]')).then(e => e.click()))
    .then(() => $browser.wait($driver.until.titleContains("You Are Logged In!"), 10000));

But re-written with async/await:

async function login(email, password) {
  await $browser.get('https://auth.example.com/');
  const email = await $browser.waitForAndFindElement($driver.By.css('input[name=email]'));
  const password = await $browser.waitForAndFindElement($driver.By.css('input[name=password]'));
  const submit = await $browser.waitForAndFindElement($driver.By.css('input[type=submit]'));

  await email.sendKeys(email);
  await password.sendKeys(password);
  await submit.click();

  await $browser.wait($driver.until.titleContains("You Are Logged In!"), 10000);
}

The above example obviously isn’t the most unreadable, since in each promise callback I only needed to do one thing. But as soon as you start throwing computations into your promise callbacks, it all of a sudden starts to get very unreadable.

Adding support for async/await in functions would mean that we have the option to make the steps that we’re performing appear a bit more sequential and easier to understand what’s going on.


New Relic edit

  • I want this, too
  • I have more info to share (reply below)
  • I have a solution for this

0 voters

We take feature ideas seriously and our product managers review every one when plotting their roadmaps. However, there is no guarantee this feature will be implemented. This post ensures the idea is put on the table and discussed though. So please vote and share your extra details with our team.


#2

Really great visualizations, @dru89! Thank you for writing in with this. I have added a poll so we can collect votes from other Explorers in the future.

Please cast your vote and know I have passed your input along to our Synthetics Product Manager, @jmarcel! Thanks!


#3

an alternative idea that i’d personally be keen to see, but i understand is far less likely to be implemented, would be the possibility of writing new relic synthetics scripts using languages that aren’t javascript.

e.g. python is a pretty ergonomic and popular language for scripting , if i got to choose which language i was making a sequence of rest api calls, i wouldn’t choose javascript.

edit:

It is possible to support async/await in the old version of ECMAScript offered by new relic by using https://facebook.github.io/regenerator/ . Regenerator compiles away async/await into plain ES5.

This lets you write monitoring scripts using async / await, compile then using regenerator, then load the output into new relic synthetics. For example, if you have a script using async / await named “foo.js”, after installing regenerator you can run: regenerator --include-runtime foo.js > out.js

A downside of this approach is that the resulting compiled scripts are not readable, and need to include a ~600 line regenerator runtime library baked into the script.


#4

Hi @Reuben.Fletcher-Cost, never say never, these ideas are always worth submitting as if there is enough support for a feature it is more likely to be implemented. I would encourage you to add this as a seperate feature idea here :slight_smile:


#5

Would like to see this in Synthetics API as well.


#6

Thanks for your input @david.germiquet - I’ll get that added to the internal feature request.