Pg-promise: Async await

[fibo]

I am using pg-promise in production with Redshift since more than one year ago and it works great, thank you for sharing this awesome package.

My question is the following: is it possible to use pg-promise with async await? Are there some examples online?

If not, I will try by myself and publish an article about this topic I can share.

[dustincjensen]

I haven't tried it myself, but any call that returns a promise can be converted to async/await assuming you are using a version of Javascript or Typescript that supports it. I don't know the versions off by heart, but here is an example (from the examples)...

db.any('SELECT * FROM users WHERE active = $1', [true])
    .then(function(data) {
        // success;
    })
    .catch(function(error) {
        // error;
    });

Would translate to...

try {
    let data = await db.any('SELECT * FROM users WHERE active = $1', [true]);
} catch (error) {
    // error
}

[vitaly-t]

ES7 async/await supports promises automatically, out of the box.

Lots of developers have been using it via Babel for a long time. And since Node.js 7.6 the async/await is available by default.

With the current Node 8.1.2 not only it all works perfectly, but 8.x shows outstanding performance improvements over the previous versions.

If not, I will try by myself and publish an article about this topic I can share.

It wouldn't be of value just in the context of pg-promise. It's a general trait of using promises.

Are there some examples online?

https://hackernoon.com/6-reasons-why-javascripts-async-await-blows-promises-away-tutorial-c7ec10518dd9

[fibo]

Cool!

@vitaly-t I am exactly in the situation described in the 4. Intermediate values section of the article you posted, thank you for sharing again.

Thank you for confirm me that this new awesome feature will work out of the box, it would be a pretty hard work to refactor the code base but it is worth to increase the readability and for other reasons.

It looks like an happy ending of the JavaScript fatigue :)

[vitaly-t]

On the final note, the real value of the new async/await syntax is when executing more than one query at a time.

When executing just one query, you typically use the root db object, with one .then and .catch, which isn't any worse or better than using a try / catch syntax that you have otherwise.

But when executing more than one query at a time, you are supposed to use tasks (see Chaining Queries), which automatically gives you access to the callback that can use the new syntax:

const result = await db.task(async t => {
    const a = await t.any('SELECT...1');
    const b = await t.any('SELECT...2');
    return {a, b};
});
// result = {a, b}

And this is how the new syntax should be used :wink:

[fibo]

Ok, I will try that syntax, thank you for the hint.

[pawelfus]

Thanks for the example @vitaly-t !

Any pros/cons over using this syntax?

try {
 const myData = await db.task(async t => {
    const a = await t.any('SELECT...1');
    const b = await t.any('SELECT...2');
    return {a, b};
  });
} catch (err) {
  logger.error(err);
}

[vitaly-t]

@pawelfus Nope. What makes you think there could be some cons?

[gvaartjes]

Because of me... ;) I'm working together with @pawelfus. We noticed errors not being catched with db.task, but later we narrowed it down to this bug in our code base.

const myAsyncFunction = (): Promise => {
   return db.task( t => {} )
}
try {
  return myAsyncFunction()
} catch (err) {
  throw new Error  // THIS WON'T BE CATCHED OBVIOUSLY... 
}

Well sorry for wasting your time, but thank you for your library... we have much pleasure working with it!

[vitaly-t]

@gvaartjes You are welcome! b.t.w. I'm currently available for hire ;)